SCR #3676 NETB 25-APR-16 NETBC Reference: 02277630 Symptom: None. Problem: File LNETINDN should be linked in from $SYSTEM.ZTCPIP.LNETINDN. Change: Changed file XPNET.NETB to link LNETINDN from $SYSTEM.ZTCPIP.LNETINDN. Implementation: Install the new NETB and NETBC files. Comment and/or uncomment desired protocols in NETB. OBEY NETBC and check spooler output for errors. When ready to implement the new network object. The example below assumes the current object is named NETWORK and new object built above is NEWNET. Rename object NETWORK to OLDNET. Rename object NEWNET to NETWORK. Stop resource nodes using the OLDNET object. Start resource nodes that were stopped above. Purge file XPNET.LNETINDN. Dependencies: XPNET 3.2 and XPNET 3.3 only. SCR #3671 XNCGEN - REL3_VER1_XNCG10_20160315 - REL3_VER2_XNCG01_20160315 - REL3_VER3_XNCG01_20160315 15-MAR-16 Reference: Case #2222442 Symptom: The OUTPUT produced by the XNCGEN program is not putting in spaces before the tilde (~) and the output looks like it is run together. For example: | | ARG [-JavaVMArgs2 -Xss1m -Xms96m -Xmx128m -XX:MaxPermSize=96m-Djav a.util.logging.config.file=/usr/bofa/aci1/WebATM/conf/logging.pr Problem: XNCGen reads the XML file in in 8192 byte chunks. It then parses that chunk. If the last byte read in is the last non space character before a ~, XNCGen will add a space to ensure a space between the next line (ARG) added to the ARG list. Change: Changed code to read the entire XML file and pass it to the parser routines. Implementation: Install new XNCGEN object file. Dependencies: None. SCR #3675 SVNCSP - (SVNCSP-32-04) SVNCSP24 - (SVNCSP24-32-04) NCSPREPT - (NCSP-REPORT-REL32-04) SVNCSP - (SVNCSP-33-01) SVNCSP24 - (SVNCSP-NET24-33-01) NCSPREPT - (NCSP-REPORT-REL33-01) Reference: 2257688 Symptom: There is code in the middle of the INIT LINE proc in the tabc file that is causing data to be overlaid. Problem: Data is being overwritten in station-table (j) entry the counter j is getting increments which leaves a blank entry in the line-table . Also added the standalone for the scr3660. Change: Move the code to the station init section in the tabc file. Implementation: Install the new objects on the XPNET subvol. Freeze / Stop/ Thaw SVNCSP/SVNCSP24. Dependencies: XPNET 3.2 and XPNET 3.3 SCR #3682 CTS - REL3^VER1^CTS13^20160729 29-JUL-16 - REL3^VER2^CTS01^20160729 - REL3^VER3^CTS01^20160729 - REL3^VER4^CTS00^20171230 Reference: 2291915 Symptom: A CTS line/station had a large queue and was in the process of coming down. It was failing the queued messages to the originator of the messages. At the time of the ZZSA the originator was a process that was in the NOM state so extra time was being taken to process for that. Eventually our "loop" timer expired and we abended. Problem: Our "loop" timer value wasn't large enough to allow for the extra processing time needed. Change: I added another SETLOOPTIMER call just before we fail messages from a CTS line/station queue to give us extra time. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: None. SCR #3667 NCPCOM - rel3^ver2^ncpc08^20160519 10-OCT-15 - rel3^ver2^ncpl08^20160519 - s32ncpl.pars04tg NCPCOM - rel3^ver3^ncpc02^20160519 - rel3^ver3^ncpl02^20160519 - s33ncpl.pars01tg Reference: help command Symptom: attributes are out of alphabetical order, duplicat or possibly in the list by error. Problem: clean up help commands Change: changed the code in the pars logic to correct the issues in the help command. Implementation: Install the new NCPCOM object. Dependencies: None SCR #3677 NCPCOM - rel3^ver2^ncpc08^20160519 19-May-16 - rel3^ver2^ncpl08^20160519 NCPCOM - rel3^ver3^ncpc03^20161018 - rel3^ver3^ncpl03^20161018 - s33ncpl.ncpl03tg - s33ncpl.ncpl01d* Reference: 02276237,2425798 Symptom: INFO STATION, OBEYFORM return wrong output. When doing INFO STATION , OBEYFORM command ENCRYPTTHENMAC attribute is returned incorrecly with no space in the attribute and the ON/OFF value causing an error when the output is used to create the station again. Addt'l changes to the obeyform were also addressed in this fix. Problem: A space is missing at the end of the attribut name when the move is performed to the pointer for format station obeyform. Change: Add a space at the end of ENCRYPTTHENMAC attribute and prevent it from generating a SET if it's already at the default. Addt'l changes to the obeyform were also addressed in this fix. Implementation: Install the new NCPCOM object. Dependencies: None SCR #3679 SVNCPI - rel3^ver3^rel02^20160731 31-JUL-16 NCPCOM - rel3^ver3^ncpc02^20160731 - rel3^ver3^ncpl02^20160731 Reference: Case #2336966 Symptom: Info station s*, Filter on INITDSTS, MAXDSTS, INTVALDSTS returns invalid data. Stations that are not Temp DSTS stations are marked as "T" Temporary instead of "E" Enabled. Problem: The NCPI SDDL for the INFO response was 2 bytes off with respect to the response from XPNET. The NCPCOM Library code was coded to look at the return value of INITDSTS, MAXDSTS, and INTVALDSTS as int32 as opposed to ints. Change: Corrected the DDL definitaion for the XPNET response in the NCPCOM DDLS (SDDLxxds) for the info station response. Coded the NCPCOM Library code to look at the return value of INITDSTS, MAXDSTS, and INTVALDSTS as integers. Implementation: Move in the new SVNCPI, from Pathcom, FREEZE and STOP all server ncpi processes. Stop the ppd name from the TACL prompt. From Pathcom THAW all server processes. Install new NCPCOM object. Dependencies: None. SCR #3684 BASE - REL3^VER3^BASE^REL01^20161201 01-DEC-16 REL3^VER3^EXEC01^20161201 Reference: Case 2475472 Symptom: XPNET3.3 - Node Abends with Trap#00011 program Alfter Stop Station (TEMP) Problem: It is possible in initialization sequences that the Station structure dynamic area that is allocated has garbage in it. This garbage can be moved into current station fields. This occurs in the DSTS DSTS^TEMPORARY^STA = 13875 field when the customer issues the following sequence of NCPCOM commands. 1) Add a STATION and make sure it's at RECORD 1 position in the NEF file 2) STOP/START the Station to make sure it's starting/stopping OK 3) STOP and START the NODE 4) STOP/START the Station at RECORD 1 position. It should fail and the node should ABEND Change: Added code to the EXEC and STA modules to determine when the call to the intialization of the dynamic area has been been made. This is needed to ensure calls to intilization done after the intial initilzation saves off the existing information in the dynamic area. The initial initilization will move zeros into the required fields. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3686 NCPCOM - REL3^VER2^NCPC09^20161229 29-DEC-16 - REL3^VER2^NCPL09^20161229 NCPCOM - REL3^VER3^NCPC04^20161229 - REL3^VER3^NCPL04^20161229 Reference: Case #02493159 Symptom: Add station fails with following error: Station add failed, prot is missing or invalid. Problem: NCPCOM was not properly initializing the station attribute TCPLISTENLINE to spaces which caused a sanity check in the XPNET node to fail and return an error. Change: Changed the NCPL logic to properly set attribute show^data.sta.det.tcp^srv^listen^line^s to spaces when required. Implementation: Install new NCPCOM module and re-issue add station command. Dependencies: None. SCR #3687 SVNCS - rel3^ver1^sncs24^20161228 28-DEC-16 SVNCS - rel3^ver2^sncs07^20170117 SVNCS - rel3^ver3^sncs02^20170116 $DATA01.S31NCS.NCS05 POBJ - T3270-N24NCS (D30) 30 DEC 2016 09:58:10 - T3270-NCS (D30) 30 DEC 2016 09:57:43 - T6520-N24NCS (D30) 30 DEC 2016 09:57:56 - T6520-NCS (D30) 30 DEC 2016 09:57:30 $DATA01.S32NCS.NCS03 POBJ - T3270-N24NCS (D42) 17 JAN 2017 13:45:47 - T3270-NCS (D42) 17 JAN 2017 13:45:20 - T6520-N24NCS (D42) 17 JAN 2017 13:45:34 - T6520-NCS (D42) 17 JAN 2017 13:45:06 $DATA01.S33NCS.NCS01 POBJ - T3270-N24NCS (D42) 19 JAN 2017 09:34:57 - T3270-NCS (D42) 19 JAN 2017 09:34:38 - T6520-N24NCS (D42) 19 JAN 2017 09:34:47 - T6520-NCS (D42) 19 JAN 2017 09:34:26 Reference: 2428075 Symptom: When executing the DELIVER command, on the response the display is offset: Process \K9.P1J^NODE.P1J^DEST0 deliver complete. Process \K9.P1J^NODE.P1J^DEST1 deliver complete. Process \K9.P1J^NODE.P1J^DEST10 deliver complete. Process \K9.P1J^NODE.P1J^DEST11 deliver complete. Process \K9.P1J^NODE.P1J^DEST12 deliver complete. Process \K9.P1J^NODE.P1J^DEST13 deliver complete. Process \K9.P1J^NODE.P1J^DEST14 deliver complete. Also the wildcarded STATUS STATION and NODE command doesn't fill the screen entries causing the operator to hit F4 more times than necessary to see all station entries. Problem: The NCS requester wasn't incrementing a pointer properly when displaying the DELIVER responses. The NCS server had set the max responses in it's reply to 15 even though it was replying with fewer entries than that which caused the requester to think it had a full screen. Change: Modified the requester to increment the pointer properly and modified the server to use the actual number of entries for the max responses field. Implementation: Install updated SVNCS on the XPNET subvol. SCUP COPY the new NCS requestor(s) to the XPNET POBJ file. Dependencies: None SCR #3689 SVNCS - REL3^VER3^SNCS02^20170116 16-JAN-17 - REL3^VER3^NCPL05^20170116 NCPCOM - REL3^VER3^NCPC05^20170116 - REL3^VER3^NCPL05^20170116 Reference: Case #02499965 Symptom: DELIVER, DISABLE, HINFO, HSTAT and NEXTOBJ commands failed from NCS Screen. Problem: During development of XPNET 3.3, the DELIVER and DISABLE command logic was inadvertently removed from the case statement in the EXECUTE procedure causing them to fail with a syntax error. The HINFO and HSTAT command logic was not correctly implemented in SVNCS. Expecting: on of or end. The NEXTOBJ command was added to the list of valid commands (in XPNET 3.1) PARSE module but the underlying logic to support it was never implemented in SVNCS or NCPCOM. This functionality is accomplished via the ENTER key from NCPCOM and the F4 or F5 function key from the NCS screen. Change: Added the DELIVER and DISABLE command back into the case statement in the EXECUTE proc in SVNCS. Added the required logic to support the HINFO and HSTAT commands in SVNCS. Removed the NEXTOBJ command from the parsing keyword table. Implementation: Install the new object files on the XPNET subvol. Freeze/Stop/Thaw SVNCS. Stop and restart NCPCOM. Dependencies: XPNET 3.3 SCR #3690 NCPCOM - REL3^VER3^NCPC05^20170116 16-JAN-17 - REL3^VER3^NCPL05^20170116 Reference: Internal Symptom: If the HSTAT PROCESS command was entered with any kind wildcard characters in the process symbolic name, only the first process matching the pattern is displayed in subsequent responses. Problem: The logic to detect when the HSTAT command is complete and the next process object matching the pattern should be displayed was not checking the correct value, so the context to the next object was not progressed. Change: Fixed the HSTAT process response logic to evaluate the correct value so it properly detects the previous object display is complete and correctly moves on to the next object. Implementation: Install the new NCPCOM module on the XPNET subvol. Stop and restart NCPCOM. Dependencies: XPNET 3.3 SCR #3688 BASE - REL3^VER3^AUD01^20170113 13-JAN-17 - REL3^VER3^BASE^REL02^20170113 BASE - REL3^VER2^AUD01^20170113 - REL3^VER2^BASE^REL08^20170113 BASE - REL3^VER1^AUD07^20170113 - REL3^VER1^BASE^REL37^20170113 Reference: Case #02500701 Symptom: XPNET is not closing the audit file once its full leading to all 3 audit files being kept open by XPNET. Problem: When the final block of data is written to the audit file, there is logic to close the current file, zero the file number out and then re-open file temporarily to write the last block/EOF marker waited. If this fails for any reason, the logic calls an entry point and bypasses the code to close the temporary file number and thus it remains open as an orphaned file. This does not create any problems until AUDITA, AUDITB and AUDITC all become full. Normally when the AUDITC file becomes full, the node will roll down and re-open AUDITA, reset the EOF to 0 and start over writing audit records to it. However, in this case, the open will fail ( because the node still has it open exclusively ) 17-01-13;13:50:57.788 \SYS.$P1AN ACI.XPNET.3100 6223 File $DATA01.P1ANAUD.AUDITA, open error 12 (file in use) When this occurs and it can't open any of the files configured ( AUDITA, AUDITB, AUDITC ) then the XPNET node will disable auditing ( programmatically issuing an ALTER NODE , AUDIT OFF command ) 17-01-13;13:50:35.720 \SYS.$P1AN ACI.XPNET.3100 6138 Fatal auditing error, auditing is stopped. If AUDERROR is CONTINUE - then the node will continue processing (without auditing). If AUDERROR is STOP, the node will ABEND. If auditing is disabled, You can ALTER NODE , AUDITA (same for AUDITB and AUDITC ) then ALTER NODE , AUDIT ON and the node will then start auditing again (until all three files become full again) If you ALTER NODE , AUDITA:B:C before the last file becomes full, it will continue auditing ( leaving the stale files open ). Until this fix is installed, the only way to close these "stale" files will be to STOP the XPNET node. Change: Added logic to insure that the temporary file is properly closed in all cases. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3691 BASE - REL3^VER1^BASE^REL38^20170213 13-FEB-17 - REL3^VER1^ONCF^ONCF06^20170213 BASE - REL3^VER2^BASE^REL09^20170213 - REL3^VER2^ONCF^ONCF01^20170213 BASE - REL3^VER3^BASE^REL03^20170213 - REL3^VER3^ONCF^ONCF01^20170213 Reference: Case #2508827 Symptom: The logic to support setting the priority on messages sent via a DELIVER Command was not working correctly, preventing the DELIVER message from being pushed to the front of the destinations object queue. Problem: During XPNET 3.1 development RPE I448 to support the addition of the MSGPRIORITY NODE attribute, new logic was added to set the msg.priority on inbound DELIVER messages. This overrode the logic added in SVNCPI for SCR 2873 to set msg.priority based on PARAM "DELIVER-PRIORITY ", preventing the ability utilize priority queuing for DELIVER messages. Change: Added additional logic to check msg.priority on inbound DELIVER messages. If the value is not equal to zero then PARAM DELIVER-PRIORITY is in use, so leave it alone. If msg.priority = 0 then use NODE MSGPRIORITY to set its value. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3692 BASE - REL3^VER3^BASE^REL04^20170223 23-FEB-17 - REL3^VER3^ONCF^LIN01^20170223 - REL3^VER3^EXEC02^20170223 Reference: Case #02505717 Symptom: After a successful ADD and DELETE LINE command completes in some cases the following can occur: INFO LINE returns NCPCOM response: Line info failed, int table invalid. INFO LINE returns NCPCOM response: Line info failed, object not found. ADD LINE returns NCPCOM response: Line add failed, associated guardian err: 10. Problem: Logic added in XPNET 3.3 to support dynamic lines and stations was not properly initializing some internal status fields. When a DELETE LINE command is issued, if the flag to indicate it is a "temporary line" (lin.dsts^temporary^lin) is set the LINE is not deleted from the NEF, but is removed from the XPNET memory tables and logs the EMS events below, which makes it look like it was deleted with no issues. 17-02-09;08:28:02.188 \SYS.$P1AN ACI.XPNET.3300 2121 LINE disabled. Previous STOPPED, Current DISABLED 17-02-09;08:28:02.188 \SYS.$P1AN ACI.XPNET.3300 7067 LINE deleted. This is what should happen if it is a dynamically added line, but not a configured line added to the NEF. When the LINE object is read from the NEF and added into the nodes memory tables, the lin.dsts^temporary^lin flag was not getting properly initialized, so if there was a non zero value at this offset in the underlying memory allocated, it will cause this problem and create different symptoms depending on the sequence of events. In most cases this value is zero, so this problem does not occur making the issue appear to be completely random. A similar problem (for STATIONS) was fixed by SCR 3684. Change: Added logic to insure lin.dsts^temporary^lin is properly reset for non-dynamic configured lines. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.3 only. SCR #3693 SVNCPI - REL3^VER2^NCP05^20170303 - REL3^VER2^NCPL10^20170303 SVNCS - REL3^VER2^SNCS08^20170303 NCPCOM - REL3^VER2^NCPC10^20170303 SVNCPI - REL3^VER3^NCP03^20170227 - rel3^ver3^ncpl06^20170227 SVNCS - REL3^VER3^SNCS04^20170303 NCPCOM - REL3^VER3^NCPC06^20170227 Reference: Case #2505681, #2524227 Symptom: unable to alter TCPCONNTIMEOUT to -1 for TCPSL station and unable to alter TCPLISTENLINE attribute for a station Problem: this field was originally to set to be < 0 and the length set was incorrect for the listenline attr. Change: changed the code to have the field set to < -1 and change the attribute length in the netcmd module. Implementation: Move in the new SVNCPI, from Pathcom, FREEZE and STOP all server ncpi processes. Stop the ppd name from the TACL prompt. From Pathcom THAW all server processes. Install the new NCPCOM module on the XPNET subvol. Stop and restart NCPCOM. Install the new SVNCS object Dependencies: XPNET 3.2 and XPNET 3.3 SCR #3700 XPMON - rel3^ver2^xpmon01^20170420 31-DEC-17 XPMON - rel3^ver3^xpmon01^20170420 XPMON - rel3^ver4^xpmon00^20171230 Reference: 2283579 Symptom: XPMON uses $0 despite the fact that a new collector name was specified with the PRI-EVT assign. Problem: Upon initialization, XPMON opens $0 as the default but once it retrieves the assigns from the GO file it never tries to re-open the new collector names. Change: Changed the code to warmboot the collector names after the ASSIGNS have been retrieved. Implementation: Move in the new XPMON code. Dependencies: none SCR #3694 NCPCOM - rel3^ver1^ncpc29^20170317 17-MAR-17 NCPCOM - rel3^ver2^ncpc11^20170317 NCPCOM - rel3^ver3^ncpc07^20170317 Reference: Case #02514679 Symptom: NCPCOM abends when user password entered is too long. This can also result in severe impacts to the EMS log file and CPU utilization. Problem: There where two code locations where the password was being loaded into to an internal data structure that did not validate its length. If the length of the password was greater than 16 bytes, adjacent fields where corrupted causing unpredictable results. For example: NCP \SYS1.P1A^NODE.* logon failed, serverclass unknown. NCP \SYS1.P1B^NODE.* logon failed, serverclass unknown. NCP \SYS1.P1C^NODE.* logon failed, serverclass unknown. NCP \SYS1.P1D^NODE.* logon failed, serverclass unknown. NCP P1E^NODE. logon failed, unkn inv hdr reason. Node \SYS1.P1I^NODE command failed, invalid command. Node \SYS1.P1I^NODE command failed, invalid command. Node \SYS1.P1I^NODE command failed, invalid command. Change: Added logic to insure that no more than 16 bytes of the password input is moved to the internal data structure. Implementation: Install the updated NCPCOM module on the XPNET subvol. Dependencies: none SCR #3698 BASE - REL3^VER1^BASE^REL39^20170407 07-APR-17 - REL3^VER1^PROC17^20170407 BASE - REL3^VER2^BASE^REL10^20170407 - REL3^VER2^PROC02^20170407 BASE - REL3^VER3^BASE^REL05^20170407 - REL3^VER3^PROC01^20170407 Reference: Case #02540216 Symptom: In some cases during initialization application processes were not passed the correct hometerm information in the standard in and standard out fields of the NSK startup message. This could cause the application to open multiple hometerms. Problem: SCR 3118 did not work as intended under certain configurations. If the process PPD was not fully qualified with a system name (i.e. \SYS.$PPD), then the hometerm of the XPNET node was passed in the NSK startup message, ignoring the configured HOMETERM attribute of the process. Change: Changed the logic that builds the NSK standard startup message to correctly format and pass the process hometerm (if configured) in the standard in and standard out fields. If the process hometerm is blanks, the hometerm of the XPNET node will continue to be passed. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3706 ===3.2=== 12-JUN-17 CCOMDC - n32ccom.ccom01dc CCOMDDDL - n32ccom.ccom01ds CCOMDTAL - n32ccom.ccom01dt CCOMDTCL - n32ccom.ccom01da ===3.3=== CCOMDC - n33ccom.ccom01dc CCOMDDDL - n33ccom.ccom01ds CCOMDTAL - n33ccom.ccom01dt CCOMDTCL - n33ccom.ccom01da Reference: Case #02579396 Symptom: Definition ETE-CONNECT-MSG is missing from XPNET.CTSDDDL. Problem: Certain definitions were moved from CTS DDL's to Common (CCOM) DDL's so they could be shared by the CTS protocol and the Internal TCP/IP protocols. Names of some definitions were changed to more common names since they are no longer specific to just CTS. Change: Added the original definitions from CTS DDL's to the CCOM DDL's and released new files named CCOM* for those DDL's. Implementation: Install the CCOM DDL files on the XPNET subvolume. Change source code that used the CTS DDL's to source/include the CCOM DDL's. If all definitions needed are in the CCOM DDL's, the existing source/include statement can be replaced. If definitions from both DDL's are needed, a source/include statement for the new CCOM DDL's must be added. The "original CTS definition names" were added to the end of each section in the CCOM DDL's for backward compatibility. You can use those variable names without need for other changes, or optionally you can change to use the new variable names at the front of each section (both sets of definitions are equivalent). SCR #3705 NCPDCOB - $data01.s33ncpi.ncpi02dx 08-JUN-17 NCPDCB74 - $data01.s33ncpi.ncpi02dv Internal Note: This required a new file EDIT00DX and updates to the NCPIxxDM file. Reference: Case #02579391 Symptom: COBOL compile errors when COPYing in sections from the XPNET 3.3 NCPD COBOL DDL's. 10240 < 04 DATA REDEFINES DATA-S NATIVE-2 ^ Problem on line 10240 ** Error 41 ** Syntax error - replacing unexpected token with COMPUTATIONAL Problem on line 10240 ^ ** Error 77 ** Duplicate clause ** Error 172 ** Missing PICTURE clause: FILLER 10334 < 02 DESTINATION PIC X(16). ^ Problem on line 10334 ** Error 36 ** Improper use of reserved word Problem: Fields added under structures NCP-RESP-HINFO-STA and NCP-RESP-HSTAT-PRO (DATA) and (DESTINATION) are 7 COBOL reserved words and caused compile errors. Change: Added an EDIT step to modify these fields in the COBOL output DDL files to prevent these errors. This step changes DATA to DATA-R and DESTINATION to PROCESS-DEST. Implementation: Install updated DDL files (NCPDCOB and NCPDCB74) and recompile program using these structures. Dependencies: XPNET 3.3. SCR #3715 3.3 POBJ - T3270-NCSS (D42) 27 SEP 2017 09:43:12 27-SEP-17 - T6520-NCSS (D42) 27 SEP 2017 09:43:22 - T3270-N24NCSS (D42) 27 SEP 2017 09:35:32 - T6520-N24NCSS (D42) 27 SEP 2017 09:35:40 3.2 POBJ - T3270-NCSS (D42) 27 SEP 2017 10:31:10 - T6520-NCSS (D42) 27 SEP 2017 10:31:19 - T3270-N24NCSS (D42) 27 SEP 2017 09:55:20 - T6520-N24NCSS (D42) 27 SEP 2017 09:55:29 3.1 POBJ - T3270-NCSS (D30) 27 SEP 2017 10:25:03 - T6520-NCSS (D30) 27 SEP 2017 10:25:13 - T3270-N24NCSS (D30) 27 SEP 2017 10:16:01 - T6520-N24NCSS (D30) 27 SEP 2017 10:16:10 Reference: Case #02634299 Symptom: XPNET NCSS requestor does not allow zeros for account expiration date field as it is documented. Problem: SCR 3585 was not coded correctly and no longer allowed a value of all zeroes in the expiration date. Change: Fixed the validation logic added by SCR 3585 to allow the expiration date to be all zeroes. Implementation: SCUP COPY the new NCSS requestor(s) to the XPNET POBJ file. Dependencies: none SCR #3702 ncpcom - rel3^ver2^NCPC12^20170601 01-JUN-17 - REL3^VER2^NCPL11^20170601 ncpcom -REL3^VER3^NCPC08^20170601 -REL3^VER3^NCPL07^20170601 Reference: 2533676 Symptom: Certain configured lines (info,detail) do not show all attributes. Problem: timer and timerint were not coded to show on the listenline, or the connection handler line Change: coded and tested the fix to now show the attributes correctly Implementation: Install the new ncpcom module on the xpnet subvol. stop and restart ncpcom. Dependencies: xpnet 3.2, xpnet 3.3 SCR #3704 BASE - REL3^VER3^BASE^REL06^20170615 15-JUN-17 - REL3^VER2^BASE^REL11^20170615 - REL3^VER3^DCOM01^20170615 - REL3^VER2^DCOM05^20170615 - REL3^VER3^ONCF^STA02^20170615 - REL3^VER2^ONCF^STA04^20170615 - REL3^VER3^ONCF^SYS01^20170615 - REL3^VER2^ONCF^SYS03^20170615 IPCL - REL3^VER3^IPCL01^20170615 - REL3^VER2^IPCL05^20170615 IPSC - REL3^VER3^IPSC02^20170615 - REL3^VER2^IPSC05^20170615 SSLLIBI - T0000H06_03_STGSSLNLIB_28OCT2016_V5R6 - T0000H06_03_ICAPLIB_28OCT2016_V5R6 - T0000H06_03_CSEVENTLIB_28OCT2016_V5R6 - T0000H06_03_PRODUCTIA_28OCT2016_V5R6 GLOBAL - N33GLBL.GLBL01TG - N32GLBL.GLBL07TG NETDDLS - N33GLBL.GDDL01DS - N32GLBL.GDDL05DS NETDC - N33GLBL.GDDL01DC - N32GLBL.GDDL05DC NETDTAL - N33GLBL.GDDL01DT - N32GLBL.GDDL05DT NETDFUP - N33GLBL.GDDL01DZ - N32GLBL.GDDL05DZ SVNCPI - rel3^ver3^rel05^20170615 - rel3^ver2^rel07^20170615 - rel3^ver3^ncp04^20170615 - rel3^ver2^ncp06^20170615 - rel3^ver3^obj04^20170615 - rel3^ver2^obj07^20170615 - rel3^ver3^rn02^20170615 - rel3^ver2^rn03^20170615 - S33NCPI.NCPRSP01 - S32NCPI.NCPRSP02 - S33NCPI.NETCMD02 - S32NCPI.NETCMD05 - S33NCPI.NETRSP01 - S32NCPI.NETRSP02 NCPDC - S33NCPI.NCPI02DC - S32NCPI.NCPI05DC NCPDCOB - S33NCPI.NCPI02DX - S32NCPI.NCPI05DX NCPDCB74 - S33NCPI.NCPI02DV - S32NCPI.NCPI05DV NCPDDDL - S33NCPI.NCPI02DS - S32NCPI.NCPI05DS NCPDFUP - S33NCPI.NCPI02DZ - S32NCPI.NCPI05DZ NCPDTAL - S33NCPI.NCPI02DT - S32NCPI.NCPI05DT NCPDTCL - S33NCPI.NCPI02DA - S32NCPI.NCPI05DA DDLC - S33SDDL.SDDL02DC - S32SDDL.SDDL03DC DDLCOB - S33SDDL.SDDL02DX - S32SDDL.SDDL03DX DDLFUP - S33SDDL.SDDL02DZ - S32SDDL.SDDL03DZ DDLS - S33SDDL.SDDL02DS - S32SDDL.SDDL03DS DDLTAL - S33SDDL.SDDL02DT - S32SDDL.SDDL03DT NCPCOM - rel3^ver3^ncpc08^20170615 - rel3^ver2^ncpc12^20170615 - rel3^ver3^ncpl07^20170615 - rel3^ver2^ncpl11^20170615 - rel3^ver3^rlbk01^20170615 - rel3^ver2^rlbk01^20170615 - S33NCPL.PREL01TG - S32NCPL.PREL04TG - S33NCPL.PARS03TG - S32NCPL.PARS05TG - S33NCPL.NCPL02DS - S32NCPL.NCPL06DS SVNCS - rel3^ver3^sncs05^20170615 - rel3^ver2^sncs09^20170615 - rel3^ver3^ncpl07^20170615 - rel3^ver2^ncpl11^20170615 - S33NCPL.PREL01TG - S32NCPL.PREL04TG - S33NCPL.PARS03TG - S32NCPL.PARS05TG - S33NCPL.NCPL02DS - S32NCPL.NCPL06DS XPNCSP - rel3^ver3^ncspcnfg^20170615 - rel3^ver2^ncspcnfg^20170615 SVNCSP24 - SVNCSP-NET24-33-03 - SVNCSP-NET24-32-04 - SVTAB-C-33-03 - SVTAB-C-32-04 NCSPREPT - NCSP-REPORT-REL33-03 - NCSP-REPORT-REL32-05 - SVTAB-C-33-03 - SVTAB-C-32-04 SVNCSP - SVNCSP-33-03 - SVNCSP-32-05 - SVTAB-C-33-03 - SVTAB-C-32-04 NETCJRD - REL3^VER3^CJRP01^170615 - REL3^VER2^CJRP02^170615 Reference: 2573930, 2578068. Symptom: N/A. Problem: SSLLIB enhancement to support Galosis/Counter Mode (GCM) for use with AES encryption and ephemeral Elliptic Curve Diffie-hellman Key exchange(ECDHE) in the internal XPNET TCPIP implementation. Change: Code was added to support new Station attributes SSLCPRAES128GCM and SSLCPRAES256GCM, these attributes default to ON. This functionality will provide GCM and ECDHE support for version 1.2 of the TLS protocol and provide the following new cipher suites: RSA_AES128_GCM_SHA256 DHE_DSS_AES128_GCM_SHA256 DHE_RSA_AES128_GCM_SHA256 DHE_DSS_AES256_GCM_SHA384 DHE_RSA_AES256_GCM_SHA384 ECDHE_RSA_AES128_GCM_SHA256 ECDHE_RSA_AES256_GCM_SHA384 ECDHE_RSA_AES256_CBC_SHA384 Added code to support the new attributes in the NCSP security code. Add code to support the SSL line attribute in the NCSP security code. Implementation: Install the new IPSC and IPCL files on the XPNET subvol. Install the new BASE file on the XPNET. Rebuild the NETWORK object using the NETBC file. Stop and start Resource Nodes using the new NETWORK object. Install the new NCPCOM and the new SVNCPI objects. Stop and start the NCPCOM module and the SVNCPI module using the new objects. Install the new NCSP module Stop and start the NCSP module using the new object. Dependencies: None. SCR #3707 BASE - REL3^VER3^BASE^REL07^20170711 25-SEP-2017 REL3^VER3^EXEC03^20170711 Reference: Internal Symptom: During XPNET 3.4 development and testing an XPNET 3.3 issue was found related to RTS support for DEST entries which may have caused them to be included in the data sent by the RTS process when they should not have been. Problem: There was some "temp" code added to set DEST RTS ON to test the RTS process logic before the ONCF code to support it was completed. It should have been removed prior to GA, but was missed. Change: Removed the "temp" test code so that the DEST RTS attribute in the NEF works as intended. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: none SCR #3710 CTS - REL3^VER1^CTS14^20170711 11-JUL-17 BASE - REL3^VER1^BASE^REL40^20170711 REL3^VER1^EXEC19^20170711 CTS - REL3^VER2^CTS02^20170711 BASE - REL3^VER2^BASE^REL12^20170711 REL3^VER2^EXEC03^20170711 CTS - REL3^VER3^CTS02^20170711 BASE - REL3^VER3^BASE^REL07^20170711 REL3^VER3^EXEC03^20170711 Reference: 2566576 and 2586877 Symptom: Customer deletes and re-adds CTS stations every day. Over time the node runs out of memory and abends with a 6410. Problem: The CTS protocol doesn't delete the connection control block for a station when it's deleted. Change: Delete the connection control block when a CTS station is deleted. Implementation: Install the new BASE and CTS files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: none SCR #3714 SVNCSS24 - SVNCSS-NET24-32-01 25-SEP-17 SVNCSS24 - SVNCSS-NET24-33-01 Reference: Case #02618095 Symptom: After updating the password on the NCSS screen for an existing user, the user cannot logon to NCPCOM: 2 > set user test1 PASSWORD: User secured for access to no nodes. Password expires in 0 days. Problem: XPNET 3.2 was enhanced to support a SHA-256 password hash. The logic to support this was added to the BASE24 (SVNCSS) and stand-alone non-pathway (XPNCSS) versions, however, the NET24 (SVNCSS24) was not properly updated to support the new hash functionality. Change: Incorporated the SHA-256 functionality into the NET24 SVNCSS24 module. Implementation: Install the updated SVNCSS24 module on the XPNET subvol. If any NCSS security records had been updated with the previous "bad" SVNCSS24 version you will have to FUP PURGEDATA on NCSS and NCSS0 and re-add the records with the new SVNCSS24 server. Dependencies: none SCR #3715 3.3 POBJ - T3270-NCSS (D42) 27 SEP 2017 09:43:12 27-SEP-17 - T6520-NCSS (D42) 27 SEP 2017 09:43:22 - T3270-N24NCSS (D42) 27 SEP 2017 09:35:32 - T6520-N24NCSS (D42) 27 SEP 2017 09:35:40 3.2 POBJ - T3270-NCSS (D42) 27 SEP 2017 10:31:10 - T6520-NCSS (D42) 27 SEP 2017 10:31:19 - T3270-N24NCSS (D42) 27 SEP 2017 09:55:20 - T6520-N24NCSS (D42) 27 SEP 2017 09:55:29 3.1 POBJ - T3270-NCSS (D30) 27 SEP 2017 10:25:03 - T6520-NCSS (D30) 27 SEP 2017 10:25:13 - T3270-N24NCSS (D30) 27 SEP 2017 10:16:01 - T6520-N24NCSS (D30) 27 SEP 2017 10:16:10 Reference: Case #02634299 Symptom: XPNET NCSS requestor does not allow zeros for account expiration date field as it is documented. Problem: SCR 3585 was not coded correctly and no longer allowed a value of all zeroes in the expiration date. Change: Fixed the validation logic added by SCR 3585 to allow the expiration date to be all zeroes. Implementation: SCUP COPY the new NCSS requestor(s) to the XPNET POBJ file. Dependencies: none SCR #3716 BASE - REL3^VER3^BASE^REL07^20170711 29-SEP-17 - REL3^VER3^ONCF^SYS02^20170929 Reference: Case #02592096 Symptom: START NODE , AUTO/WARM fails and then incorrectly reports the node state as abnormal NODE> start node p1a^node, auto Node \SYS1.P1A^NODE start failed, node not started. NODE> status Node \SYS1.P1A^NODE status failed, cmd inv in state abnormal. Problem: Changes added during XPNET 3.3 to support some new internal functionality inadvertently broke the START NODE command when the WARM or AUTO modifiers are specified. Change: Fixed the START NODE logic to function properly when the AUTO or WARM modifiers are specified. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.3 SCR #3709 SKELB - REL3^VER1^SUTL25^20171004 04-OCT-17 SKELLIST SKELB - REL3^VER2^SUTL04^20171004 SKELLIST SKELB - REL3^VER3^SUTL01^20171004 SKELLIST Reference: #02575212 Symptom: An application process trying to log a message using a PCI LMCF abends with a trap 2 (arithmetic overflow ) and the stack looks like this: 0 TAL #GGS_OS_STOP.#834(GUARD) + %122I 1 TAL #PROCESS_STOP_.#10275(ASYSTE) + %121I 2 TAL #TRAP^DUMP.#1191(DLIB05TS) + %10I 3 TAL #LOGMESSAGE.#8208(SUTL19TS) 4 TAL #LOG^MESSAGE^.#10027(SUTL19TS) 5 TAL #CAA^STM^0200^TO^SEM^RQST.#29971(SAAS) 6 TAL #ADA^STM^0200^REQUEST.#21498(SAAS) + %4I 7 TAL #AD^STM^^INPUT^FROM^PROCESS.#21356(SAAS) + %5I 8 TAL #SAA^A0^40.#5078(SAAS) + %4I Problem: While parsing the PCI LMCF record for the directive field, it's position on the stack caused the trap 2 because of the use of signed arithmetic. Change: Modified the signed arithmetic to un-signed arithmetic. Implementation: Since SKELB is run aa user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: None SCR #3712 BASE - REL3^VER1^BASE^REL41^20171010 10-OCT-17 - REL3^VER1^GATE16^20171010 BASE - REL3^VER2^BASE^REL13^20171010 - REL3^VER2^GATE02^20171010 BASE - REL3^VER3^BASE^REL08^20171010 - REL3^VER3^GATE01^20171010 Reference: #02626648 Symptom: Event message 7069 is logged incorrectly. Problem: The wrong token macro is being called attempting to pass an address verses a value. The only impact on the running node is the 7069 event failed to get logged. Change: Changed the code where the 7069 gets created to use the tkn^val fields instead of the tkn^addr fields that it was pointing to. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependancies: None SCR #3717 BASE - REL3^VER3^BASE^REL08^20171010 30-OCT-17 - REL3^VER3^DCOM02^20171031 BASE - REL3^VER2^BASE^REL13^20171010 - REL3^VER2^DCOM06^20171031 Reference: Case - 2643850 Symptom: SSL Certificate file with zero EOF is held open by XPNET when accessed by altering a device to point to that file with the SSLCERTSFILE attribute. Problem: When loading the certsfile into the SSL memory segment within XPNET on an alter device SSLCERTSFILE command if the certsfile has a zero length the create segment fails and the file is not closed. Change: Added code to close the certsfile when a create segment call fails when loading a certsfile into the SSL memory segment within Xpnet. Implementation: Install the new files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none SCR #3720 NCPCOM - rel3^ver3^ncpl08^20171030 30-OCT-17 rel3^ver3^ncpc09^20171030 BASE - REL3^VER3^BASE^REL08^20171010 REL3^VER3^ONCF^SYS03^20171030 REL3^VER3^DCOM02^20171031 NCPCOM - rel3^ver2^ncpc13^20171030 rel3^ver2^ncpl12^20171030 BASE - REL3^VER2^BASE^REL13^20171010 REL3^VER2^ONCF^SYS04^20171030 REL3^VER2^DCOM06^20171031 Reference: Case 2626992 Symptom: Customer reports the following: Other testing reveals that the following is still not working: Control node p5a^node,rootsrefresh $******.******.certfile Control Node \INGI21.P5A^NODE unkn cmd completed. 3.6 > info station *,SSLCPRAES128GCM info station *,SSLCPRAES128GCM ^ Expecting: one of: ABNORMAL CONFIGURED CONNECTED CONTROLLER DETAIL DISABLED ENABLED EVTINFO FORMATVARS OBEYFORM PRIORITY Q Problem: 1) The command actually completes the intended function, the issue is that the display of "unkn cmd completed" is not the correct response on the command return. There is a code issue that selects that string in error. 2) Code to handle the filtering for the VTY's for SSLCPRAES128GCM and SSLCPRAES256GCM were not added the the SYS code. Change: 1) Added code to properly handle the response from a control node p5a^node,rootsrefresh $******.******.rootsfile & control node p5a^node,certsrefresh $******.******.certfile and display the proper completon status. 2) Added cdoe to handle the VTY's for SSLCPRAES128GCM and SSLCPRAES256GCM for filtering in the SYS code. Implementation: Install the new BASE and CTS files on XPNET subvol. Rebuild the NETWORK object using the NETB file. Stop and re-start all nodes affected. Dependencies: none SCR #3721 BASE - REL3^VER1^BASE^REL41^20171010 25-OCT-17 - REL3^VER1^ONCF^DEST08^20171025 BASE - REL3^VER2^BASE^REL14^20171025 - REL3^VER2^ONCF^DEST01^20171025 BASE - REL3^VER3^BASE^REL09^20171025 - REL3^VER3^ONCF^DEST01^20171025 Reference: Internal Symptom: No symptom for production nodes. This only occurs on internal ACI development systems when testing marking/checkpointing functionality. Problem: The "marking tools" discovered a problem when command "status dest *" is executed. The last portion of data being moved due to that command was not marked. The problem doesn't occur every time, it depends on the contents of the response buffer when it is allocated. This should cause no harm, but it needs to be changed so the "marking tools" do not identify it causing research effort each time it occurs. Change: Corrected the move that builds the status response buffer so that buffer is marked properly. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3722 BASE - REL3^VER1^BASE^REL41^20171010 24-OCT-17 - REL3^VER1^ONCF^SYS21^20171024 BASE - REL3^VER2^BASE^REL13^20171010 - REL3^VER2^ONCF^SYS04^20171030 BASE - REL3^VER3^BASE^REL08^20171010 - REL3^VER3^ONCF^SYS03^20171030 Reference: Internal Symptom: No symptom for production nodes. This only occurs on internal ACI development systems when testing marking/checkpointing functionality. Problem: Problem discovered when command "RESETSTATS NODE " is executed. The ndf.reset^timestamp was modified, but not "marked" again after that change. This should cause no harm, as the NDF was already marked to be checkpointed so no data loss would occur in the event of cpu failure/takeover. However, this needs to fixed so the "marking tools" do not identify it as a mismatch causing research effort each time it occurs. Change: Added logic to correctly "mark" the NDF to prevent the verify memory/mark errors from occurring. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SC #3723 BASE - REL3^VER2^BASE^REL13^20171010 24-OCT-17 - REL3^VER2^PROC03^20171024 BASE - REL3^VER3^BASE^REL08^20171010 - REL3^VER3^PROC02^20171024 Reference: Internal Symptom: No known symptoms for production nodes. This only occurs on internal ACI development systems when testing marking/checkpointing functionality. Problem: Problem found when an application process replies with data and the msg^usize > 0. There were two problems identified. First, the length of the message userdata was counted twice when allocating the memory for message to be routed, so the memory used was larger than what was required. The second problem was when the message reply data in the processes dedicated buffer was moved to the memory location of the new message allocated. The textlen was also too long so extra data could be copied past the end of the message. When "marking" the message/memory to be checkpointed, this extra data is not included causing a marking / verify memory mismatch error. As this extra data is not actually part of the message it does not need to be checkpointed, so this is not an issue from a data loss perspective in the event of a CPU failure. However, this needs to fixed so the "marking tools" do not identify it as a mismatch causing research effort each time it occurs. Change: Changed the logic to correctly calculate the size of message when allocating and moving the message. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3724 BASE - REL3^VER1^BASE^REL41^20171010 25-OCT-17 - REL3^VER1^EXEC20^20171025 BASE - REL3^VER2^BASE^REL14^20171025 - REL3^VER2^EXEC04^20171025 BASE - REL3^VER3^BASE^REL09^20171025 - REL3^VER3^EXEC04^20171025 Reference: Internal Symptom: No symptom was discovered at customer sites. This was only discovered on internal ACI development systems marking/checkpointing functionality. Problem: The "marking tools" discovered a problem when adding a Process or Station through NCPCOM that has the same symbolic name as a destination that was previously added manually. A work area was modified and not "marked", thus causing the "marking tools" to identify that issue. Change: Added code to "mark" the work area that was modified. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3726 BASE - REL3^VER1^BASE^REL41^20171010 25-OCT-17 - REL3^VER1^ONCF^SYS21^20171025 BASE - REL3^VER2^BASE^REL14^20171025 - REL3^VER2^ONCF^SYS05^20171025 - REL3^VER2^DCOM07^20171025 BASE - REL3^VER3^BASE^REL09^20171025 - REL3^VER3^ONCF^SYS04^20171025 - REL3^VER3^DCOM03^20171025 Reference: Internal Symptom: No symptom was discovered at customer sites. This was only discovered on internal ACI development systems marking/checkpointing functionality. Problem: The "marking tools" discovered a problem when adding a Process or Station through NCPCOM that has the same symbolic name as a destination that was previously added manually. A work area was modified and not "marked", thus causing the "marking tools" to identify that issue. Change: Added code to "mark" the work area that was modified. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3708 SVNCPI - REL3^VER2^REL08^20170707 07-JUL-17 - REL3^VER2^NCP07^20170707 - REL3^VER2^EVT01^20170707 - REL3^VER2^MEM01^20170707 - REL3^VER2^OBJ08^20170707 - REL3^VER2^SEC01^20170707 - REL3^VER2^TIM01^20170707 - REL3^VER2^RN04^20170707 - REL3^VER2^UT02^20170707 - REL3^VER2^BKUP01^20170707 SVNCPI - REL3^VER3^REL06^20170707 - REL3^VER3^NCP05^20170707 - REL3^VER3^EVT01^20170707 - REL3^VER3^MEM01^20170707 - REL3^VER3^OBJ05^20170707 - REL3^VER3^RN03^20170707 - REL3^VER3^SEC02^20170707 - REL3^VER3^TIM01^20170707 - REL3^VER3^UT01^20170707 - REL3^VER3^BKUP01^20170707 Reference: Case #02593623 Symptom: SERVER-NCPI abends when entering DEST object commands. 17-06-29;14:50:16.088 \SYS1.$P1AU ACI.XPSNCPI.3200 3 NCPI internal memory data structures are corrupted - dumping. 17-06-29;14:50:16.091 \SYS1.$P1AU ACI.XPSNCPI.3200 43 NCPI backup stopped SERVER-NCPI-1A 17-06-29;14:50:16.091 \SYS1.5,946 TANDEM.EMS.H01 512 ABEND- PROGRAM $SYSTEM.XPNET.SVNCPI, Trap #01000 Problem: When using XPNET 3.2 in Base24-Classic, the DESTS INUSE parameter was always less than 5000. After installing Base24-EPS 2.0.7 the DESTS INUSE in the node increased to 46000+. One of the internal data structures (list^def) utilized by SVNCPI to build object lists to do sorting and pattern matching, etc used an integer for the number of items in the list. This is not an issue for any object type other than DEST which can only have 4095 or less per XPNET node. However, the number of dests is dynamic and can be large depending on the size of the system, the number of services and the level of inter-node routing, etc. This was not an issue if the DESTS INUSE for a single resource node was less than 32767. If the number of items in the list was > 32767, some of the logic did not function properly (with signed arithmetic the count was negative) and unpredictable results, corruption, abends could occur. Change: Changed LIST^DEF to utilize INT(32) counters. This required many additional code changes as this structure was highly referenced and used throughout the modules as well as these variables were being used as indexes into other structures (which only allowed integers -32,768 through 32,767). It also required an upgrade of the Guardian memory pool procedures being utilized (due to the increase in the size of memory blocks being allocated). Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCA macro (OCANCPI) for Itanium and X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or from NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: none SCR #3727 SVNCPI - REL3^VER1^REL22^20171201 08-DEC-17 - REL3^VER1^NCP19^20171201 - REL3^VER1^OBJ14^20171201 - REL3^VER1^RN11^20171201 SVNCPI - REL3^VER2^REL09^20171201 - REL3^VER2^NCP08^20171201 - REL3^VER2^OBJ09^20171201 - REL3^VER2^RN05^20171201 SVNCPI - REL3^VER3^REL07^20171201 - REL3^VER3^NCP06^20171201 - REL3^VER3^OBJ06^20171201 - REL3^VER3^RN04^20171201 Reference: Case #02670838 Symptom: Customer had a higher than expected transaction volume hit the system, which caused queuing and invoked NOM on the interface to VISA. They then attempted to issue DELIVER PRO command from NCPCOM, that message queued up behind everything else and went into the NOM file. Problem: Customer did not have PARAM DELIVER-PRIORITY configured to set the msg^priority on the DELIVER message and there was no way to set the NOM override flag for DELIVER messages. Change: Added a new parameter "DELIVER-NOMOVERRIDE ON/OFF" for SVNCPI to provide the ability to set the DELIVER msg^nom^override flag in the message header. By default, all DELIVER messages have a msg^nom^override set to 0. If this parameter is specified it will apply to all deliver commands(PROCESS, STATION & DEST) on that node. Implementation: Install new SVNCPI object file. Edit the pathconf and add SET SERVER PARAM DELIVER-NOMOVERRIDE to each SERVER-NCPI-?? definition you want this to apply to. Stop all the NCPI servers from TACL. Shutdown the pathway system and obey PATHCOLD. Dependencies: None SCR #3730 SVNCS - rel3^ver1^sncs25^20180110 10-JAN-18 SVNCS - rel3^ver2^sncs10^20180110 SVNCS - rel3^ver3^sncs06^20171230 SVNCS - rel3^ver4^sncs01^20180110 Reference: Case #02635374 Symptom: When executing a STATUS STATION *, DETAIL or STATUS NODE *, DETAIL command from NCS, an invalid subscript error occurs (termination status 00003, termination substatus 00000) and exits the screen. Problem: The logic added in SCR 3687 to insure the wildcard STATUS STATION * and STATUS NODE * command fills the screen did not account for the "DETAIL" modifier. This caused the NCS requestor to send another request for additional data which then created an invalid subscript. Change: Added code to check to see if the "DETAIL" modifier was specified before invoking the logic added by SCR 3687. Implementation: Install updated SVNCS on the XPNET subvol. Freeze, stop, stop, thaw SERVER-NCS. Dependencies: None SCR #3736 SVNCPI - REL3^VER3^REL08^20180430 30-APR-18 - REL3^VER3^NCP07^20180430 - REL3^VER3^OBJ07^20180430 SVNCPI - REL3^VER4^REL02^20180430 - REL3^VER4^NCP02^20180430 - REL3^VER4^OBJ02^20180430 NCPDC - S33NCPI.NCPI03DC - S34NCPI.NCPI02DC NCPDCOB - S33NCPI.NCPI03DX - S34NCPI.NCPI02DX NCPDCB74 - S33NCPI.NCPI03DV - S34NCPI.NCPI02DV NCPDDDL - S33NCPI.NCPI03DS - S34NCPI.NCPI02DS NCPDFUP - S33NCPI.NCPI03DZ - S34NCPI.NCPI02DZ NCPDTAL - S33NCPI.NCPI03DT - S34NCPI.NCPI02DT NCPDTCL - S33NCPI.NCPI03DA - S34NCPI.NCPI02DA Reference: Case #02731635 Symptom: NCPCOM commands fail with various errors. ALTER LINE , OUTPUT Line output failed, object not found. ALTER LINE , ORIGINATE Line originate failed, int table invalid. ALTER LINE , PRTLUNAME Line prtluname failed, int err, bad cmd subtype. ALTER LINE , OSIMGR Line osimgr failed, int table invalid. ALTER LINE , POLLINT Line pollint failed, object not found. Problem: The CTYP (command type) for new commands added during XPNET 3.3 development (HINFO STATION, HSTAT STATION, HSTAT PROCESS, HSTAT LINK, HSTAT DEST) inadvertantly overlapped the above LINE command types which caused the wrong vty (variable type) and object type to be sent to the XPNET node. The new commands worked as expected, however, it caused the ALTER LINE commands to fail. Change: Changed HINFO STATION, HSTAT STATION, HSTAT LINK, HSTAT DEST and HSTAT PROCESS command types to be unique as they should have been to allow all commands to work as expected. Implementation: Install the new SVNCPI object and the NCPD* DDL's on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or from NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: XPNET 3.3 and 3.4. Code Review: CR-XPNET-39 SCR #3742 NCPCOM - REL3^VER2^NCPC14^20180810 10-aug-18 REL3^VER2^NCPL13^20180810 NCPCOM - REL3^VER3^NCPC10^20180810 REL3^VER3^NCPL09^20180810 NCPCOM - REL3^VER4^NCPC02^20180810 REL3^VER4^NCPL02^20180810 Reference: Case #2771963 Symptom: The info obeyform on the device was looping in ncpcom. Problem: A change was made in 3.2 which caused the info obeyform on the device to loop when this is ran in ncpcom. Change: Corrected the loop in ncpl to prevent this from occurring. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.2, 3.3, 3.4 SCR #3743 SVNCSP24 - SVNCSP-NET24-33-04 30-aug-18 SVNCSP-NET24-34-01 SVNCSP - SVNCSP-33-04 SVNCSP-34-01 Reference: case #2770417 Symptom: Stack overflow when running SVNCSP. Problem: Customer was running SVNCSP with the Golden Gate library and ran out of room on the stack. Change: Moved some structures from the WORKING-STORAGE section to the EXTENDED-STORAGE section. Implementation: Install the new SVNCSP and SVNCSP24 modules on the xpnet subvolume. Dependencies: XPNET 3.3 and 3.4 Code Review: CR-XPNET-48 SCR #3748 PWS - rel3^ver0^pws07^181129 29-NOV-18 PATHTPLS - $data01.n30pws.pws03ps PATHTPLO - $data01.n30pws.pws03po Reference: 2793513 Symptom: The client sends a message to PWS which is sent to XPNET. The client gets a zero length reply and the response is queued at the XPNET station. Problem: The client is using the new SERVERCLASS_SENDL_ call. The maximum reply size parameter is set to a value larger than 32,767. PWS uses a signed integer for the parameter which causes the maximum reply size value in PWS to be a negative number. PWS thinks the client is asking for a zero length response. PWS replies immediately with a zero length response and doesn't read the response from XPNET. Change: Altered PWS to determine that the maximum reply size is invalid. If invalid, PWS replies to the client with an error 21 ( illegal count specified ) and generates event message 1341 indicating that the maximum reply count is invalid. Implementation: Restore the PATHTPLS and PATHTPLO files to the XPNET subvolume. Remake the XPNET templates using SCRIBE.TMPLMAKE, and then remake all EMS templates using the SCRIBE.GOINST macro. Install the new PWS module, Stop and restart the PWS process. Dependencies: None. Code Review: CR-XPNET-52 SCR #3745 XNCGEN - REL3_VER1_XNCG11_20181030 30-OCT-18 - REL3_VER2_XNCG02_20181030 - REL3_VER3_XNCG02_20181030 - REL3_VER4_XNCG01_20181030 Reference: Case #2771925 Symptom: It used to be the case that you could span processes on any desired system. However when I try to start the CTSE process by setting the Process Program attribute preceded by the remote System Id, the process abends. Problem: XNCGEN upshifted the Internal filename of the Default Startup subvol, the IN and OUT Startup file after it was resolved from the External filename. The Internal filename has a numeric representation of the system number. If the system number is in the range of an ASCII lower case alpabetic value the upshift will change the value of the system number. Change: The change made is to Up-shift the Exteranl filename before resolving to the Internal filename for the affected attributes. Implementation: Install new XNCGEN object file. Dependencies: none Code Review: CR-XPNET-xxx SCR #3749 SKELB - REL3^VER1^SUTL26^20181228 28-DEC-18 SKELLIST - $DATA01.N31SUTL.SUTL26TL SPRT01 - REL3^VER1^SPRT01^20181228 SPRT01B - SPROUTE 01 Bind File SPRT01BC - SPROUTE 01 Bind Obey File SPRTEXP - SPROUTE 01 Spooler Listing File Reference: case #2833509 Symptom: New Customer IIN ranges need to be added to skel and sproute per mandate Problem: New customer IIN ranges need to be added for sproute mapping. Change: Changes have been implemented in SKELB and in the Sprt** modules to add the new IIN ranges for the customer. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. Code Review: CR-XPNET-053 SCR #3728 BASE 3.3 - REL3^VER3^BASE^REL11^20190110 30-DEC-17 - REL3^VER3^AUD02^20181130 - REL3^VER3^EXEC05^20181130 - REL3^VER3^NSTP01^20181130 - REL3^VER3^PROC03^20180912 - REL3^VER3^ONCF^PRO01^20181130 - REL3^VER3^ONCF^SYS05^20181130 BASE 3.4 - REL3^VER4^BASE^REL03^20190110 - REL3^VER4^EXEC01^20181130 - REL3^VER4^PROC01^20180912 RTS - REL3^VER3^RTS01^20181130 - REL3^VER4^RTS01^20181130 SVNCPI - REL3^VER3^REL09^20181130 - REL3^VER3^NCP08^20181130 - REL3^VER3^OBJ08^20181130 - REL3^VER3^RN05^20181130 - S33NCPI.NCPRSP02 - S33NCPI.NETCMD03 - S33NCPI.NETRSP02 NCPDC - S33NCPI.NCPI03DC NCPDCOB - S33NCPI.NCPI03DX NCPDCB74 - S33NCPI.NCPI03DV NCPDDDL - S33NCPI.NCPI03DS NCPDFUP - S33NCPI.NCPI03DZ NCPDTAL - S33NCPI.NCPI03DT NCPDTCL - S33NCPI.NCPI03DA DDLC - S33SDDL.SDDL03DC DDLCOB - S33SDDL.SDDL03DX DDLFUP - S33SDDL.SDDL03DZ DDLS - S33SDDL.SDDL03DS DDLTAL - S33SDDL.SDDL03DT NCPCOM - REL3^VER3^NCPC11^20181130 - REL3^VER3^NCPL10^20181130 - REL3^VER3^RLBK02^20181130 - S33NCPL.PREL02TG - S33NCPL.PARS04TG - S33NCPL.NCPL03DS SVNCS - REL3^VER3^SNCS08^20181130 - REL3^VER3^NCPL10^20181130 - S33NCPL.PREL02TG - S33NCPL.PARS04TG - S33NCPL.NCPL03DS XPNCSP - REL3^VER3^NCSPCNFG^20171230 SVNCSP24 - SVNCSP-NET24-33-04 - SVTAB-A-33-02 NCSPREPT - NCSP-REPORT-REL33-04 - SVTAB-A-33-02 SVNCSP - SVNCSP-33-04 - SVTAB-A-33-02 NETCJRD - REL3^VER3^CJRP02^171230 Reference: Internal Symptom: N/A Problem: N/A Change:           Moved module from the 3.4 enhancement effort to N33RTS RTS01TS. Assumptions made when intially developing RTS based on conversations with IR were changed in the 3.4 development cycle. Change Highlights: 1) Connection handling, all message types will be sent dowm each connection. This will allow Each RTS process to support up to 3 consumers. 2) Removed the initial message type. 3) Added Tcpretries handling for lost connections. 4) Added HSTAT message for the node. 5) Corrected the TCPIPPRO obeyform from TCPIPPROCESS to TCPIPPRO. Implementation: Install the new NCPCOM and the new SVNCPI objects. Stop and start the NCPCOM module and the SVNCPI module using the new objects. Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3740 BASE - REL3^VER1^BASE^REL43^20180712 12-JUL-18 - REL3^VER1^PROC18^20180912 BASE - REL3^VER2^BASE^REL15^20180912 - REL3^VER2^PROC04^20180912 BASE - REL3^VER3^BASE^REL11^20190110 - REL3^VER3^PROC03^20180912 BASE - REL3^VER4^BASE^REL03^20190110 - REL3^VER4^PROC01^20180912 Reference: Case #02751516 Symptom: XPNET abnormally terminates with trap #6665 after NCPCOM command ALTER NODE , BCPU (stopping and starting backup PIN) followed immediately by NCPCOM command SWITCH NODE . Problem: The issue is the checkopen of a file number (LINK or application PROCESS) had not completed successfully during the backup restart as the result of the ALTER BCPU before the SWITCH NODE command which performs a takeover was issued. This caused that backup to became the primary with that file number not open. As a result of this, the node dispatched an I/O tag to attempt to cleanup and reopen that file number for the LINK or application process. The issue was that it failed an internal sanity check (file number open but no I/O was in progress). Change: Updated the logic that caused trap #6665 (process file number is not zero and process output in progress is false) to also check the following: if the IOCB (I/O control block) for that file number = 0d and the error = 202 (takeover) then continue processing the cleanup/reopen instead of abending to handle this timing issue/sequence of events, otherwise abend with trap #6665. Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: None SCR #3744 BASE - REL3^VER1^BASE^REL43^20180712 12-SEP-18 - REL3^VER1^EXEC21^20180912 - REL3^VER1^PROC18^20180912 BASE - REL3^VER2^BASE^REL15^20180912 - REL3^VER2^EXEC05^20180912 - REL3^VER2^PROC04^20180912 BASE - REL3^VER3^BASE^REL11^20190110 - REL3^VER3^EXEC05^20180912 - REL3^VER3^PROC03^20180912 BASE - REL3^VER4^BASE^REL03^20190110 - REL3^VER4^EXEC01^20180912 - REL3^VER4^PROC01^20180912 Reference: case #2794585 Symptom: XPNET node abends when starting an external process after altering its DEVICE XNCONF NODE 19 > START PROCESS TCPSRV^1^ZEXP1 Process \SYS1.P1A^NODE.TCPSRV^1^ZEXP1 start failed, file sys err: 201 Problem: The external process was previously DISABLED. When a process is disabled some specific logic is not invoked (and should not be). Part of this is fixing up the data related to the device and XPCONF associated with that process. When the process was ENABLED, the node did not properly "fix up" all of the data and pointers and left the address pointing to its device invalid (0d). The logic to start the process assumed the pointer was valid, accessed the device data for this process and caused an invalid address trap in subproc LOAD^XNCPRO^DATA in proc PROCESS^CONTROL^TASK. Change: Updated the logic when the ENABLE PROCESS command is invoked to properly "fix up" its data and pointers. This will prevent the address trap from occuring. Also added logic in subpro LOAD^XNCPRO^DATA to validate the process device address before attempting to access it to prevent possible future abends. If the process device address is not set, the START PROCESS command will fail and event 2122 will be generated: 18-09-13;10:49:00.564 \SYS1.$P1AN ACI.XPNET.3300 2122 Process TCPSRV^1^ZEXP1 XNCONF error 19031 (Fixup of the XNconf entry for this process failed) Previous STARTING, Current ABNORMAL Implementation: Install the new BASE on XPNET subvol. Rebuild the NETWORK object using the NETB Dependencies: none SCR #3750 BASE - rel3^ver3^base^rel12^20190125 25-jan-19 NSTP - rel3^ver3^nstp02^20190125 BASE - rel3^ver4^base^rel04^20190125 NSTP - rel3^ver4^nstp01^20190125 GLOBAL - N33GLBL.GLBL03TG GLOBAL - N34GLBL.GLBL02TG Reference: Case #2806197 Symptom: The release information is incorrect. Problem: in log #7019 the XPNET release is showing incorrectly shows Release 3.20 instead of Release 3.30 or 3.40 Change: corrected the release in the globals Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: XPNET 3.3, XPNET 3.4 SCR #3753 CTSE - REL3_VER0_CTSE33_021519 15-FEB-19 TCPCLI - REL3_VER0_TCPC60_021519 TCPSRV - REL3_VER0_TCPS65_021519 SSLSRV - REL3_VER0_SSLS43_021519 SSLCLI - REL3_VER0_SSLC42_021519 Reference: Case #2857175 Symptom: Many ZZSA files during startup of new CTS stations. Problem: On startup of the SSLCLI process the primary was able to open the supplied STDOUT file, it then closes it. The primary then proceeds to start the backup process. On startup the backup process CRE library tries to open STDOUT and fails causing the code to ABEND. The SSLCLI receives a "Process deletion system message" and tries to restart the backup. This continues, saveabends are produced until the open is successful or no more saveabends can be created. Change: Code was added to configure a backup retry param. This param is used when a "Process deletion system message" for the backup is received. If the backup retry param is not zero the primary will try to open STDOUT. If the backup retry param is zero then the primary will set the backup to disabled. Each failed attempt to open STDOUT will decrement the backup retry param. New Param was added: Param BKUPRETRY default = 5. GOTCPCLI/SRV setting of new param: param bkupretry 8 Tell command added for #BKUPRST tell external $gcli.#BKUPRST, "BKUPRETRY 6" New log messages 19-02-27;16:38:44.438 \NODE.$GCLI ACI.XPCTSE.3000 1027 Backup Retries will be 5 times. 19-02-27;16:33:24.942 \NODE.$GCLI ACI.XPCTSE.3000 1027 Backup Retries will be 8 times. 19-02-27;16:34:48.830 \NODE.$GCLI ACI.XPCTSE.3000 1029 Backup Retries reset to 6 times. 19-02-27;16:34:48.830 \NODE.$GCLI ACI.XPCTSE.3000 1020 Backup enabled. Implementation: Move in the new SSL/TCP modules. Stop associated XPNET stations. Stop and re-start SSL/TCP processes. Re-start the previously stopped stations. Dependencies: none SCR #3754 TCPCLI - REL3_VER0_TCPC60_021519 15-FEB-19 SSLCLI - REL3_VER0_SSLC42_021519 Reference: Case #02861262 Symptom: XPNET TCPCLI Abends with out error. Problem: An invalid IP address was configured in the raddr for a CTS Client station. ex. 0.xx.xx.xx. For HP TCPIPv6 and Conventional stacks the invalid raddr was accepted, the CONNECT_NW() was done without error. However due to the invaold IP addr eventually returned a 4126 ETIMEOUT error which is a retryable error. In the case of a CLIM stack a error 4022 EINVAL is returned on a CONNECT_NW() this error was coded to abend. Change: Intial coding of the TCPCLI process incorporated the EINVAL error code for debugging purposes. The change is to remove the EINVAL error code from the abend logic and handle it as a retryable error. Implementation: Move in the new SSL/TCP modules. Stop associated XPNET stations. Stop and re-start SSL/TCP processes. Re-start the previously stopped stations. Dependencies: none SCR #3756 BASE - REL3^VER4^BASE^REL05^20190412 12-APR-19 - REL3^VER4^AUD01^20190412 BASE - REL3^VER3^BASE^REL13^20190412 - REL3^VER3^AUD03^20190412 BASE - REL3^VER2^BASE^REL16^20190412 - REL3^VER2^AUD02^20190412 BASE - REL3^VER1^BASE^REL44^20190412 - REL3^VER1^AUD08^20190412 Reference: 02890104 Symptom: XPNET node abends with a trap 6538 in fesclose after altering AUDIT OFF. Problem: Logic added by SCR 3688 did not account for the possibility the audit file number could be negative (fesopen returns a -1 in the file number if the open fails for any reason). If the file number was not 0 it attempted to close it. The logic in fesclose did not expect a file number with an negative value and failed a sanity check and abended. Change: Changed the logic added by SCR 3688 to only close the audit file if the file number is greater than 0. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-63 SCR #3760 NCPCOM - REL3^VER1^NCPC30^20190503 06-MAY-19 REL3^VER1^NCPL27^20190503 NCPCOM - REL3^VER2^NCPC15^20190503 REL3^VER2^NCPL14^20190503 NCPCOM - REL3^VER3^NCPC12^20190503 REL3^VER3^NCPL11^20190503 NCPCOM - REL3^VER4^NCPC03^20190503 REL3^VER4^NCPL04^20190503 Reference: Cases 2871369 and 2881007 Symptom: When obeying an obeyform file attempting to add a device, results are unpredictable following a SET statement containing MACRO and the device is not added. Problem: An uninitialized pointer could cause random issues. Change: Properly initialized the pointer. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.1, 3.2, 3.3, 3.4 Code Review: CR-XPNET-66 SCR #3761 NCPCOM - REL3^VER2^NCPC15^20190503 03-MAY-19 REL3^VER2^NCPL14^20190503 NCPCOM - REL3^VER3^NCPC12^20190503 REL3^VER3^NCPL11^20190503 NCPCOM - REL3^VER4^NCPC03^20190503 REL3^VER4^NCPL04^20190503 Reference: cases 2885028 Symptom: When obeying an obeyform file with a ,cpu the file loops. Problem: A display needed to be increased. Change: Increased the display field in ncpl. Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.2, 3.3, 3.4 Code Review: CR-XPNET-66 SCR #3764 OCANCPI - $DATA01.S34NCPI.OCA01AS 23-MAY-19 OXANCPI - $DATA01.S34NCPI.OXA01AS OCANCPI - $DATA01.S33NCPI.OCA01AS OXANCPI - $DATA01.S33NCPI.OXA01AS OCANCPI - $DATA01.S32NCPI.OCA02AS OCANCPI - $DATA01.S31NCPI.OCA01AS Reference: Case #02902380 Symptom: SVNCPI object is being accelerated with OCAX. OCAX/out $S.#oxa.SVNCPI, name / SVNCPI, output_file SVNCPIA, obey ZZoxa04 *** ERROR *** OCAX failed with completion code 1 See $S.#oxa.SVNCPI for error information. OCAX - T0892L01 - (Apr 8 2017 08:36:06) Copyright 2017 Hewlett Packard Enterprise Development LP. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 2. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 3. *** Warning 15: Procedure SEC^GUARD^VERIFY^CPC at offset 0217 in file SVNCPI inherits register 4. Problem: New warnings from the acceleration of SVNCPI. Change: Updated the OCANCPI and OXANCPI to remove warnings. OXANCPI #append oxa_cmds INHERITSR2 SEC^GUARD^VERIFY^CPC #append oxa_cmds INHERITSR3 SEC^GUARD^VERIFY^CPC #append oxa_cmds INHERITSR4 SEC^GUARD^VERIFY^CPC OCANCPI #append oca_cmds INHERITSR2 SEC^GUARD^VERIFY^CPC #append oca_cmds INHERITSR3 SEC^GUARD^VERIFY^CPC #append oca_cmds INHERITSR4 SEC^GUARD^VERIFY^CPC Implementation: Install updated OCANCPI and OXANCPI and obey the macro. Dependencies: none Code Review: CR-XPNET-69 SCR #3757 SVNCPI - REL3^VER4^REL04^20190424 24-APR-19 - REL3^VER4^SEC01^20190424 SVNCPI - REL3^VER3^REL10^20190424 - REL3^VER3^SEC03^20190424 SVNCPI - REL3^VER2^REL10^20190424 - REL3^VER2^SEC02^20190424 SVNCPI - REL3^VER1^REL23^20190424 - REL3^VER1^SEC05^20190424 Reference: Case #02768094 Symptom: SERVER-NCPI abends when executing a DELIVER command with the CPCONF in use. Problem: There was an uninitialized pointer on the stack in procedure SEC^GUARD^WARMBOOT^CPC. This happened to point at the beginning of the memory pool and corrupted the memory pool header. Once this occurs, any call to pool_getspace_ causes SVNCPI to trap and abend. Stack trace could be one of the following: Num Lang Location ABEND 0 TAL #TRAP^DUMP.#1528(DLIB00TS) + %10I 1 TAL #MEMPOOL^ALLOC.#354(MEM00TS) + %15I 2 TAL #LIST^OBJ^CONS.#947(UT00TS) + %7I 3 TAL #OBJECT^POP^GET^PATT^LIST.#4970(OBJ11TS) + %3I 4 TAL #COMMAND^EXEC_INIT.#5298(NCP11TS) + %142I 5 TAL #COMMAND^EXEC.#4912(NCP11TS) + %7I 6 TAL #REQUEST^EXEC^COMMANDS.#19102(NCP11TS) + %23I 7 TAL #LINK^INIT^REQUEST.#16077(NCP11TS) + %6I 8 TAL #RCV^USER^MSG.#17931(NCP11TS) + %6I 9 TAL #REL4^VER0^NCP00^20191230.#4314(NCP11TS) + %6I Num Lang Location ABEND 0 TAL #EVT^CONS.#830(EVT00TS) + %3I 1 TAL #RN^CONNECT_CREATE^NCPCOM.#3072(RN01TS) + %20I 2 TAL #TRAP^DUMP.#1521(DLIB00TS) + %5I Change: Changed the code to use a local variable on the stack in procedure SEC^GUARD^WARMBOOT^CPC instead of a pointer. Found the same problem in procedure SEC^GUARD^VERIFY^CPC so fixed that as well. Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or from NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: none Code Review: CR-XPNET-64 SCR #3762 SVNCPI - REL3^VER4^REL05^20190516 16-MAY-19 - REL3^VER4^NCP04^20190521 - REL3^VER4^OBJ04^20190516 - REL3^VER4^SEC02^20190516 - REL3^VER4^RN02^20190516 - REL3^VER4^BKUP01^20190516 SVNCPI - REL3^VER3^REL11^20190516 - REL3^VER3^NCP09^20190521 - REL3^VER3^OBJ09^20190516 - REL3^VER3^SEC04^20190516 - REL3^VER3^RN06^20190516 - REL3^VER3^BKUP02^20190516 SVNCPI - REL3^VER2^REL11^20190516 - REL3^VER2^NCP09^20190521 - REL3^VER2^OBJ10^20190516 - REL3^VER2^SEC03^20190516 - REL3^VER2^RN06^20190516 - REL3^VER2^BKUP02^20190516 Reference: Case #02902380 Symptom: XPNET34 EXTAUD* params give error when ONCF security is enabled and access should be allowed. ALTER NODE *, EXTAUDPRI $TEST.P1ANAUDP Node \SYS1.P1A^NODE extaudpri failed, invalid security. Problem: The new attributes added under XPNET 3.4 are secured in the second NCSP record. SVNCPI was only looking in the first NCSP record, so the command was not found and failed security. Change: Added logic to check the second NCSP record if the command is not found in the first NCSP record. Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or From NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: None Code Review: CR-XPNET-67 SCR #3765 SVNCPI - REL3^VER4^REL06^20190620 20-JUN-19 - REL3^VER4^NCP05^20190620 - REL3^VER4^EVT01^20190620 - REL3^VER4^MEM01^20190620 - REL3^VER4^OBJ05^20190620 - REL3^VER4^RN03^20190620 - REL3^VER4^SEC03^20190620 - REL3^VER4^TIM01^20190620 - REL3^VER4^UT01^20190620 - REL3^VER4^BKUP02^20190620 SVNCPI - REL3^VER3^REL12^20190620 - REL3^VER3^NCP10^20190620 - REL3^VER3^EVT02^20190620 - REL3^VER3^MEM02^20190620 - REL3^VER3^OBJ10^20190620 - REL3^VER3^RN07^20190620 - REL3^VER3^SEC05^20190620 - REL3^VER3^TIM02^20190620 - REL3^VER3^UT02^20190620 - REL3^VER3^BKUP03^20190620 SVNCPI - REL3^VER2^REL12^20190620 - REL3^VER2^NCP10^20190620 - REL3^VER2^EVT02^20190620 - REL3^VER2^MEM02^20190620 - REL3^VER2^OBJ11^20190620 - REL3^VER2^RN07^20190620 - REL3^VER2^SEC04^20190620 - REL3^VER2^TIM02^20190620 - REL3^VER2^UT03^20190620 - REL3^VER2^BKUP03^20190620 Reference: Case #02902380 Symptom: NCPCOM commands fail with the following error: PATHSEND error 904, server link error (Guardian error 201) SVNCPI creates saveabend file with the following stack: Num Lang Location ABEND 0 TAL #PROGRAMMATIC^DUMP.#1454(DLIB00TS) + %10I 1 TAL #BKUP^CHECKPOINT.#909(BKUP01TS) + %4I 2 TAL #REL3^VER4^NCP04^20190521.#4246(NCP04TS) Problem: Changes added by SCR 3762 to support the second NCSP record increased the size of the globals in SVNCPI. This caused the call to checkpointmanyx during backup creation to fail because the stackbase + globals increased to 34,496 bytes which is above the 32,500 limit for non native applications. This causes SVNCPI to call abend. This only occurs when the SVNCPI is configured to run with a backup. In the server definition in the pathconf the CPUS attribute has two CPU numbers specified. Change: Added logic to create a new flat segment for the memory required for the NCSP records instead of in globals. Implementation: Install the new SVNCPI object on the XPNET subvol. Accelerate SVNCPI using the OCANCPI macro for Itanium and OXANCPI for X.86 platforms to avoid performance issues. From TACL: STOP <$NCPI PPD> or From NCPCOM: DELIVER NODE , "ABORT-NCPI" Dependencies: None Code Review: CR-XPNET-70 SCR #3766 BASE - REL3^VER4^BASE^REL06^20190805 05-AUG-19 - REL3^VER4^ONCF^PRO01^20190805 BASE - REL3^VER3^BASE^REL14^20190805 - REL3^VER3^ONCF^PRO02^20190805 Reference: Case 2935064 Symptom: There is a XNCONF defined to a satellite process (XPNETSTARTUPSEQ ON). After the process is started the following command is issued: INFO PRO *,DEVICE The network abends in the proc shown below. Notice the address for INFO^RSP^ is zero: #11 0x704854e0 in BUILD^PRO^INFO^RESP (PRO^=0x60ecbdb8, INFO^RSP^=0x0) at \OMA3T06.$DATA01.N34ONCF.PRO00TS:1515 Problem: A call to PROCESS_GETINFOLIST_ passed the wrong return value max length. It was twice as large as it should have been. Prior to the X.86 this didn't cause an issue. On the X.86 it caused it to walk on the INFO^RSP^ address. Change: Modified the call to PROCESS_GETINFOLIST_ to pass the correct length for the return value max length field. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-72 SCR #3767 SVNCSP - SVNCSP-34-03 20-AUG-19 - SVTAB-A-34-02 SVNCSP24 - SVNCSP-NET24-34-03 - SVTAB-A-34-02 NCSPREPT - NCSP-REPORT-REL34-02 - SVTAB-A-34-02 SVNCSP - SVNCSP-33-06 - SVTAB-A-33-03 SVNCSP24 - SVNCSP-NET24-33-06 - SVTAB-A-33-03 NCSPREPT - NCSP-REPORT-REL33-05 - SVTAB-A-33-03 Reference: Case #02926884 Symptom: Unable to secure PROCESS attributes REMOTEADDR2, REMOTEADDR3 and REMOTEPORT1 in the NCSP file. Problem: When the new logic in the TABA module was added to support these new attributes, the table index was not incremented properly causing them to not be added to the table and not referenced on the screen. Change: Fixed the logic to properly increment the index. Implementation: Install new modules on the XPNET subvol. Dependencies: none Code Review: CR-XPNET-073 SCR #3768 RTSSAT - rel3^ver4^rts03^20190822 22-AUG-19 RTSSAT - rel3^ver3^rts03^20190822 Reference: Case #02947303 Symptom: Duplicate stations showing in Prognosis display. Problem: The NonStop Node in RTS header contained trailing spaces in state change messages and nulls in the status change messages. This caused prognosis to detect these as different objects. The logic in the RTS process did not properly initialize the variable being used to store the NonStop Node name and if it was less than 8 characters there could be nulls/garbage in the field which was then moved into the RTS header. The RTS state change messages are created in the XPNET Node which properly cleared out the field and insured it was filled in for the actual node name length instead of 8 as the RTS process was. Change: Modified the RTS process to properly initialize the NonStop Node name and only move the system name for its actual length. Implementation: Install new modules on the XPNET subvol. Dependencies: none Code Review: CR-XPNET-074 SCR #3770 BASE - REL3^VER4^BASE^REL07^20190911 11-SEP-19 - REL3^VER4^QUE01^20190911 GLOBAL - N34GLBL.GLBL03TG BASE - REL3^VER3^BASE^REL15^20190911 - REL3^VER3^QUE01^20190911 GLOBAL - N33GLBL.GLBL04TG BASE - REL3^VER2^BASE^REL17^20190911 - REL3^VER2^QUE02^20190911 GLOBAL - N32GLBL.GLBL08TG BASE - REL3^VER1^BASE^REL45^20190911 - REL3^VER1^QUE09^20190911 GLOBAL - N31GLBL.GLBL19TG Reference: Case #02940233 Symptom: XPNET Node abends with a trap #11 after QWRITE command in procedure QWRITE^CMD^IT^TIMER + 0xC80 (UCr) when it was moving the [0,0] EOF marker to the file. Problem: The XPNET logic moving the last EOF marker was using an INT .EXT pointer instead of a STRING .EXT pointer. This caused extra bytes to be moved past the actual EOF of the named file. This only causes an issue if the actual size of the file (named QWRITE segment) ends on a 16k boundary ( i.e. 32768, 65535 ). The underlying memory allocated (by Guardian) for the segment is created using 16k blocks. If the EOF is on a 16k boundary, the move goes past the end of the memory and causes the address trap. If the EOF is not on an exact 16k boundary, there is slack at the end of the file/memory block and no trap occurs. Change: Changed the logic to use a STRING .EXT file address pointer which prevents the move from going past the EOF. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-075 SCR #3771 BASE - REL3^VER4^BASE^REL07^20190911 11-SEP-19 - REL3^VER4^QUE01^20190911 BASE - REL3^VER3^BASE^REL15^20190911 - REL3^VER3^QUE01^20190911 BASE - REL3^VER2^BASE^REL17^20190911 - REL3^VER2^QUE02^20190911 Reference: Case #02927208 Symptom: XPNET abends in procedure ENQUEUE when attempting to process and ADD NODE command. Problem: The XPNET process was unable to open the NEF file (error 48) so it did not set the address of the NDF pointer and was generating an EMS event to indicate the open failed, called ENQUEUE to queue the event message to the internal log queue. The logic in ENQUEUE checked to see if it should update the MAX QUEUE COUNT TIMESTAMP if @NDF <> -1d. The issue was @NDF was set to 0D, so attempted to access the NDF and trapped. Change: Added an additional check to make sure @NDF <> 0d before attempted to access it. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-076 SCR #3773 BASE - REL3^VER4^BASE^REL08^20191130 30-NOV-19 - REL3^VER4^DCOM03^20191130 BASE - REL3^VER3^BASE^REL16^20191130 - REL3^VER3^DCOM05^20191130 BASE - REL3^VER2^BASE^REL18^20191130 - REL3^VER2^DCOM08^20191130 Reference: Case #2929387 Symptom: BASE24-eps 2.1.11 (NSK-X) - Since migration to NSK X machine TXN STATS Entry Time is invalid. Problem: A variable that is not initialized and is referenced after a possible path in which it is not updated. On the Itanium it is always set to Zero prior to the decision point. On the X86 the value varies. It is referenced after the decision point assuming that it would be Zero if not updated Change: Intialize the variable to Zero at declaration. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none SCR #3758 XNCGEN - REL1_VER0_XNCG00_20191230 30-DEC-19 CPCGEN - REL1_VER0_CPCG00_20191230 RPCGEN - REL1_VER0_RPCG00_20191230 Reference: Internal Symptom: For many years XPNET has been using an older version of the open source ExPat XML Parser which has known security (CVE) vulnerabilities. Problem: Every time a new version of XPNET was released or a new CVE was reported it created additional work and issues in ACI's third party vulnerability tracking and management to mark them as not applicable. XPNET is not using the parser in a web facing role, so those vulnerabilities do not pose a risk from a security standpoint. Change: It was determined that XPNET's requirements were limited and upgrading to the current version of the ExPat XML parser was not needed. In addition, we would still face the same issues if any new CVE's were reported. So an internal XML parser was written and the open source version was removed from XNCGEN, RPCGEN and CPCGEN to avoid the overhead associated with maintaining a third-party open source module. Implementation: Install the updated versions of CPCGEN, RPCGEN and XNCGEN. Dependencies: None. Applies to all versions of XPNET. Code Review: CR-XPNET-82. SCR #3776 CTS - REL3^VER4^CTS01^20200219 19-FEB-20 - REL3^VER3^CTS03^20200219 - REL3^VER2^CTS03^20200219 - REL3^VER1^CTS15^20200219 Reference: case #2935333 Symptom: - Node Dump with Trap Dump 6559 when INPUT OFF/ON Command set on Line Problem: If a connection exists and the station is stopped/ aborted the code does not initialize conn^cb.conn^id. If a Disable Input is done on the line cts^send^disable^input^sig^rcv is called which transitions the code into the closed state and signals the RECV FSM to stop. When the Enable Input is done on the line cts^send^enable^input^sig^rcv is called. In this proc a check is done on the conn^cb.conn^id. If this is set to a valid connection id the code will incorrectly signal a start. This causes the code to post a RECV when the filenum is set to -1 which causes the dump 6559. The filenum was correctly set to -1 when the stations was stopped. Change: Set the conn^cb.conn^id to -1 once the line nc pending has occurred. Implementation: Install the new CTS file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. Code Review: CR-XPNET-89 SCR #3772 SUTL - rel3^ver4^sutl02^20190927 27-SEP-19 SUTL - rel3^ver3^sutl03^20190927 SUTL - rel3^ver2^sutl06^20190927 SUTL - rel3^ver1^sutl27^20190927 Reference: Case #02959487 Symptom: VISA abended for unknown reason. Problem: The log^messageX code is doing signed moves which causes an arithemetic overflow when the data pointer passed in by the calling routine is over 32735 and under 32763. Change: Modified the SUTL log^messageX code to move the pointer using unsigned moves. Implementation: Since SKELB is run aa user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file. Dependencies: none Code Review: CR-XPNET-xxx SCR #3777 SKELB - REL3^VER1^SUTL28^20200320 20-mar-20 SKELLIST - $DATA01.N31SUTL.SUTL28TL SPRT01 - REL3^VER1^SPRT0x^20200320 SPRT01B - SPROUTE 0x Bind Fileisting File SPRT01BC - SPROUTE 0x Bind Obey File SPRTEXP - SPROUTE 0x Spooler Listing File Reference: case:na Symptom: New Customer IIN ranges need to be added to skel and sproute per mandate Problem: New customer IIN ranges need to be added for sproute mapping. Change: Changes have been implemented in SKELB and in the Sprt** modules to add the new IIN ranges for the customer. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB and listed SPRT files on the XPNET subvol. Examine the SPRTEXP file to determine which version of SPRTvv to link into SKELB. Obey the SPRTvvBC to build the updated version of SKELBvv. Rename SKELB out of the way and then rename SKELBvv to SKELB. If on a RISC machine, accelerate SKELB as shown in the SKELAXCL file otherwise accelerate SKELB as shown in the OCASKELB. Dependencies: In order to utilize the SPRT module, the version of SKELB installed must be equal or newer than the ones listed in this SCR. Code Review: CR-XPNET-090 SCR #3781 04/09/20 BASE - REL3^VER3^BASE^REL17^20200409 - REL3^VER3^ONCF^STA04^20200409 BASE - REL3^VER4^BASE^REL09^20200409 - REL3^VER4^ONCF^STA02^20200409 BASE - REL4^VER0^BASE^REL01^20200409 - REL3^VER4^ONCF^STA01^20200409 Reference: Case #02799744 Symptom: Unable to Alter Station Param SBRDISTGLOBAL. Problem: Protocol CTS was not supported for this attribute Change: Modified the STATION code to include CTS as a supported Protocol. Implementation: Install the new BASE file on the XPNET subvol Rebuild the NETWORK object using the NETBC file. Stop and start Resource Nodes using the new NETWORK object. Dependencies: none SCR 3780 04/07/2020 SVNCPI - REL4^VER0^OBJ01^20200407 - REL4^VER0^REL01^20200407 - s40ncpi.ncprsp01 SVNCPI - REL3^VER4^OBJ06^20200407 - REL3^VER4^REL07^20200407 - s34ncpi.ncprsp01 SVNCPI - REL3^VER3^OBJ11^20200407 - REL3^VER3^REL13^20200407 - s33ncpi.ncprsp03 Reference : #2959405 Symptom: Statistics station * shows TCP stations as temporary Problem: The NCPRSP table has a previous release value in the latest version. Change: Change was made in NCPRSP01 to include the current release Implementation: Install the new SVNCPI object on the XPNET subvol Accelerate SVNCPI using OCA macro (OCANCPI) for Itanium and (OXANCPI) for X.86 platforms to avoid performance issues. From TACL: STOP or from NCPCOM: DELIVER NODE ,"ABORT-NCPI" Dependencies: none Code Review: CR-XPNET-95 SCR #3784 04/17/20 SVNCPI - REL3^VER3^REL14^20200417 - REL3^VER3^OBJ12^20200417 - s33ncpi.netcmd04 SVNCPI - REL3^VER4^REL08^20200417 - REL3^VER4^OBJ07^20200417 - s34ncpi.netcmd01 SVNCPI - REL4^VER0^REL02^20200417 - REL4^VER0^OBJ02^20200417 - s40ncpi.netcmd01 Reference : #3076629 Symptom: LOGN Total counter doesn't clear on the RESETSTATS NODE , COUNTERS command Problem: The latest version of the NETCMDxx file mapped that command to ncp^vty^mod^none instead of ncp^vty^mod^counters Change: Changed the table to use ncp^vty^mod^counters Implementation: Install the new SVNCPI object on the XPNET subvol Accelerate SVNCPI using OCA macro (OCANCPI) for Itanium and (OXANCPI) for X.86 platforms to avoid performance issues. From TACL: STOP or from NCPCOM: DELIVER NODE ,"ABORT-NCPI" Dependencies: None. Code Review: CR-XPNET-98 SCR #3792 06/08/20 jb NCPCOM - rel4^ver0^ncpl01^20200608 - rel4^ver0^ncpc01^20200608 SVNCS - rel4^ver0^sncs01^20200608 NCPCOM - rel3^ver4^ncpl05^20200608 - rel3^ver4^ncpc04^20200608 SVNCS - rel3^ver4^sncs02^20200608 NCPCOM - rel3^ver3^ncpl12^20200608 - rel3^ver3^ncpc13^20200608 SVNCS - rel3^ver3^sncs09^20200608 Reference: cases 03099494 Symptom: When obeying an obeyform file with MACRO attribute INPUTFORMAT and OUTPUTFORMAT don't get populated. Problem: SCR 3760 initialized a pointer but did not fill it with the correct value. Change: Added code back that filled the pointer's location Implementation: Install the new ncpcom module on the xpnet subvol. Stop and restart ncpcom. Dependencies: XPNET 3.3, 3.4, 4.0 Code Review: CR-XPNET-105 SCR #3799 08/14/2020 jb NETADRD -REL3^VER3^audr01^20200814 NETADRD -REL3^VER4^audr01^20200814 NETADRD -REL4^VER0^audr01^20200814 NETADRT -REL4^VER0^audt01^20200814 Reference: H24-166300 03141495 Symptom: NETADRD Prints Type 9 record to the screen but does not put it in the QWRITE file Problem: When 9 was used for PURGE and POP, it was not included in NETADRD as a TYPE that can use QWRITE Change: Added type 9 to QWRITE logic. Implementation: Install the new NETADRD program. Dependencies: None Code Review: CR-XPNET-110 SCR #3786 05/01/2020 jb BASE - REL3^VER3^BASE^REL18^20200501 - REL3^VER3^EXEC06^20200501 - REL3^VER3^MMGR01^20200501 BASE - REL3^VER4^BASE^REL10^20200501 - REL3^VER4^EXEC02^20200501 - REL3^VER4^MMGR01^20200501 BASE - REL4^VER0^BASE^REL02^20200501 - REL4^VER0^EXEC01^20200501 - REL4^VER0^MMGR01^20200501 Reference: INTERNAL Symptom: NETWORK abends out of memory. Problem: 1) The Station control block not being released when the station is deleted with non-cts protocols. 2) The allocators^id^to^name table missing literals. Change: 1) Removed the protocol check before calling the routine that deletes the control block. 2) added missing literals to the table. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-106 SCR #3798 08/15/20 BASE - REL4^VER0^BASE^REL04^20200820 - REL4^VER0^ONCF^SYS02^20200820 NCPCOM - REL4^VER0^NCPC02^20200820 - REL4^VER0^NCPL02^20200820 BASE - REL3^VER4^BASE^REL11^20200820 - REL3^VER4^ONCF^SYS02^20200820 NCPCOM - REL3^VER4^NCPC05^20200820 - REL3^VER4^NCPL06^20200820 BASE - REL3^VER3^BASE^REL19^20200820 - REL3^VER3^ONCF^SYS06^20200820 NCPCOM - REL3^VER3^NCPC14^20200820 - REL3^VER3^NCPL13^20200820 Reference: H24-99772 Symptom: The SSLMED attribute was not correctly populating when the node restarted. Problem: There were some original coding omissions for the SSLMED/ SSLMAT attributes that were not behaving as expected. Change: Code was changed to update the SSLMED/SSLMAT attributes to work as the expected behavior. Implementation: Install the new BASE file on XPNET subvol and rebuild the NETWORK object using the NETB file. Install the new NCPCOM on the XPNET subvol and stop and restart NCPCOM. Dependencies: XPNET 3.3, 3.4, and 4.0 Code Review: CR-XPNET-109 SCR #3801 N24SEG - $DATA01.U33N24S.N24S03AS 06-Oct-20 N24SEG - $DATA01.U34N24S.N24S04AS N24SEG - $DATA01.U40N24S.N24S02AS Reference: Internal Symptom: Running out of low pins on the system. Problem: There are too many processes running low pin. Change: To help alleviate the problem, N24SETUP will now create the TCP process to have HIGHPIN set to ON. Implementation: Replace N24SEG on the XPNET subvol with the new version. Dependencies: XPNET 3.3. 3.4 and 4.0 Code Review: CR-XPNET-111 SCR #3803 mmn OCT-23-20 SKELB - REL3^VER3^SUTL05^20201023 SKELLIST - REL3^VER3^SUTL05^20201023 POBJ - T3270-LMCF-PCI (D42) 26 OCT 2020 10:28:01 - T6520-LMCF-PCI (D42) 26 OCT 2020 10:27:55 SKELB - REL3^VER4^SUTL04^20201023 SKELLIST - REL3^VER4^SUTL04^20201023 POBJ - T3270-LMCF-PCI (D42) 26 OCT 2020 10:35:16 - T6520-LMCF-PCI (D42) 26 OCT 2020 10:35:10 SKELB - REL4^VER0^SUTL02^20201023 SKELLIST - REL4^VER0^SUTL02^20201023 POBJ - T3270-LMCF-PCI (D42) 26 OCT 2020 10:40:25 - T6520-LMCF-PCI (D42) 26 OCT 2020 10:40:19 Reference: Internal (XPNET-779) Symptom: (ISO) Board announced its intent to migrate from the current six-digit IIN to an eight-digit standard. IINs are the six-digit numeric assets assigned to card-issuing financial institutions. Problem: XPNET only allows for a max of 6 characters of the PAN prefix and 4 characters of the suffix to be shown in EMS events when implementing PCI masking via the LMCF (See SCR 3440). Change: Changed the PCI LMCF requestor to allow 999 to be entered in the PAN DIGITS field, verses previous limit of 694. Changed SKELB to support these new values. To support backward compatibility, if PAN length is in the previous range 13 - 19 then the previous mask rule enforced - prefix max of 6 and suffix max of 4 displayed depending on max mask length and prefix length. If the length of the PAN passed to log^message is greater than 19 and less than 29 then new mask rule enforced - prefix max of 9 and suffix max of 9 displayed in EMS depending on max mask len and prefix length. Implementation: SCUP COPY the updated LMCF-PCI requester into your working POBJ. Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Accelerate the SKELB module via the OCASKELB or OXASKELB. Update the PAN DIGITS in the appropriate LMCF records. Dependencies: none Code Review: CR-XPNET-115 SCR #3795 07/14/20 jb Reference: BASE - REL3^VER3^BASE^REL20^20200901 - REL3^VER3^SEG01^20200901 BASE - REL3^VER4^BASE^REL12^20200901 - REL3^VER4^SEG01^20200901 BASE - REL4^VER0^BASE^REL06^20200901 - REL4^VER0^SEG01^20200901 Symptom: Network abend when clearing RPC from device when audit is on and processing traffic for the station. Production (NS2200) B Node Abnormality Problem: Stations associated with lines that are disabled do not get device RPC changes which can cause invalid pointers. Change: Added code to segment^delete^by^dev so it will remove the RPC and XNC files from all stations disbaled or enabled. Implementation: Install the new BASE file on XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none Code Review: CR-XPNET-123 SCR #3808 12/14/2020 jb BASE - REL3_VER3_REL20_201214 - REL3_VER3_DCOM06_201214 - REL3_VER3_STA05_201214 BASE - REL3_VER4_REL12_201214 - REL3_VER4_DCOM04_201214 - REL3_VER4_STA03_201214 BASE - REL4_VER0_REL06_201214 - REL4_VER0_DCOM02_201214 - REL4_VER0_STA02_201214 Reference: 03176663 H24-234267 Symptom: Dynamic station issues from customer testing. Problem: PREFIX is truncated when it creates dynamic stations/lines Using RADDR causes more stations to be created then asked for. Naming convention for lines/stations isn't consistent. Change: Added logic to allow PREFIX to be variable length. added logic to disallow RADDR with TEMPLATE. added logic to use "S" as the first character of a station like "L" is used in the first character of a line. Implementation: Move in the new BASE module. Stop XPNET template & temporary stations. restart the node start XPNET template stations (it will start temp stations) Dependencies: none Code Review: CR-XPNET-123 SCR #3816 03/23/2021 jb NCPCOM - rel3^ver3^ncpc15^20210323 SVNCS - rel3^ver3^sncs10^20210323 - rel3^ver3^ncpl14^20210323 NCPCOM - rel3^ver4^ncpc07^20210323 SVNCS - rel3^ver4^sncs04^20210323 - rel3^ver4^ncpl08^20210323 NCPCOM - rel4^ver0^ncpc05^20210323 SVNCS - rel4^ver0^sncs04^20210323 - rel4^ver0^ncpl05^20210323 Reference: H24-253627 03234219 Symptom: QVIEW DETAIL when more than a page is needed to display the message makes NCPCOM abend. Problem: There wasn't code to handle a single message that was longer then a page. Change: Added logic to continue to display past the one page limit of previous releases. Implementation: Move the new files into XPNET subvol, restart NCPCOM and/or SVNCS. Dependencies: none Code Review: CR-XPNET-129 SCR #3817 3/26/2021 jb SKELB - REL3^VER3^SUTL06^20210326 SKELLIST - REL3^VER3^SUTL06^20210326 SKELB - REL3^VER4^SUTL05^20210326 SKELLIST - REL3^VER4^SUTL05^20210326 SKELB - REL4^VER0^SUTL03^20210326 SKELLIST - REL4^VER0^SUTL03^20210326 Reference: H24-278984 03261735 Symptom: 8 Digit BIN does not get displayed when PAN is less than 20 digits long. Problem: An invalid assumption was used during developement and based on that the change did not affect the PAN's with lengths that are less then twenty Change: Removed code that set the prefix based on the size of the PAN to allow for 8 digit BIN's to be displayed with the same size PAN's as were used with 6 digit BINs. Implementation: Since SKELB is run as a user library, do the following only after taking appropriate action to avoid library conflicts. Install SKELB on the XPNET subvol. Accelerate the SKELB module via the OCASKELB or OXASKELB. Update the PAN DIGITS in the appropriate LMCF records. Dependencies: none Code Review: CR-XPNET-130 SCR #3819 07/08/21 jb BASE - REL3^VER3^BASE^REL21^20210708 REL3^VER3^EXEC07^20210708 REL3^VER4^BASE^REL14^20210708 REL3^VER4^EXEC03^20210708 REL4^VER0^BASE^REL09^20210708 REL4^VER0^EXEC03^20210708 CTS - REL3^VER3^CTS04^20210708 REL3^VER4^CTS02^20210708 REL4^VER0^CTS02^20210708 IPCL - REL3^VER3^IPCL07^20210708 REL3^VER4^IPCL06^20210708 REL4^VER0^IPCL03^20210708 IPSC - REL3^VER3^IPSC08^20210708 REL3^VER4^IPSC06^20210708 REL4^VER0^IPSC03^20210708 Reference: H24-328773 03316277 Symptom: Node went abnormal and abended after deleting a line. Problem: A restart timer had been set for that line before it was deleted, so when the timer popped and we attempted to access the line, it was gone. Change: Added code to remove the timer when a line gets deleted (CTS, IPCL, and IPSC were all affected by this) Implementation: Move in the new modules. Rebuild the NETWORK object using the NETB file. Restart the NETWORK processes. Dependencies: none Code Review: CR-XPNET-134 SCR #3826 11/12/21 jb BASE - REL3^VER3^BASE^REL22^20211112 - REL3^VER3^ONCF^SYS07^20211112 BASE - REL3^VER4^BASE^REL15^20211112 - REL3^VER4^ONCF^SYS03^20211112 BASE - REL4^VER0^BASE^REL10^20211112 - REL4^VER0^ONCF^SYS03^20211112 BASE - REL4^VER1^BASE^REL01^20211112 - REL4^VER1^ONCF^SYS01^20211112 Reference H24-368422 Symptom: NETWORK unable to close the trace file. Problem: When more than one trace is started, the previous file is not closed until the network is restarted. Change: Made starting a second trace an error. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None Code Review: CR-XPNET-144 SCR #3827 11/16/21 jb RELPROC - $data01.u10relp.relp00as Reference Internal Symptom: Compiled date/time not for the module listed. Problem: ENOFT and XNOFT return an error when trying to list source on some modules, causing us to be off when pulling from the various _list variables. Change: Added code to recongize the error condition and report no data for that module. Removed 700 code logic and moved the module to U10RELP. Implementation: Install the new files on the XPNET subvol. Dependencies: None Code Review: CR-XPNET-145 SCR #3830 12/07/2021 mmn BASE - REL4^VER1^BASE^REL02^20211207 - REL4^VER1^NSTP01^20211207 - REL4^VER1^EXEC01^20211207 BASE - REL4^VER0^BASE^REL11^20211207 - REL4^VER0^NSTP02^20211207 - REL4^VER0^EXEC04^20211207 BASE - REL3^VER4^BASE^REL16^20211207 - REL3^VER4^NSTP03^20211207 - REL3^VER4^EXEC04^20211207 BASE - REL3^VER3^BASE^REL23^20211207 - REL3^VER3^NSTP03^20211207 - REL3^VER3^EXEC08^20211207 GLOBAL - n41glbl1.glbl01 GLOBAL - n40glbl1.glbl01 GLOBAL - n34glbl1.glbl04 GLOBAL - n33glbl1.glbl05 NETTPLS - n41ems.ems01ps - n40ems.ems01ps - n34ems.ems01ps - n33ems.ems01ps NETTPLO - n41ems.ems01po - n40ems.ems01po - n34ems.ems01po - n33ems.ems01po NETETCL - n41ems.ems01ea - n40ems.ems01ea - n34ems.ems01ea - n33ems.ems01ea NETEC - n41ems.ems01ec - n40ems.ems01ec - n34ems.ems01ec - n33ems.ems01ec NETEDDL - n41ems.ems01es - n40ems.ems01es - n34ems.ems01es - n33ems.ems01es NETETAL - n41ems.ems01et - n40ems.ems01et - n34ems.ems01et - n33ems.ems01et NETECOB - n41ems.ems01ex - n40ems.ems01ex - n34ems.ems01ex - n33ems.ems01ex Reference: Case 3367557, 3367446 Symptom: Multiple error 30's generated on various processes and stations. 21-11-18;13:32:00.643 \PROD.$P1AN ACI.XPNET.3300 6200 A Guardian writeread error 30 (unable to obtain main memory space for a link control block) to Process P1A^REF2 occurred 21-11-18;13:32:00.644 \PROD.$P1AN ACI.XPNET.3300 2105 Station S1A^L1^0098 on Line L1A^L1^0098 closed because of a fatal Guardian error 30 (unable to obtain main memory space for a link control block), station will remain closed. Previous STARTING, Current ABNORMAL Problem: The number of started processes and stations caused the number of outstanding incoming messages to the XPNET node and or the number of outstanding messages sent by the XPNET node to exceed the values (4095) passed to CONTROLMESSAGESYSTEM resulting in error 30's on various file opens in the node. This can happen when too many objects are configured and started in a single XPNET node. Although the number configured is below the architectural limit of 4095 per object type, there is a practical limit that may require you to add an additional XPNET node and move some of these processes/stations to the new node. Change: Increased the values passed to CONTOLMESSAGESYSTEM from 4095 to 16383. This should prevent the error 30's, however, there is still a practical limit that may require you to horizontally scale by adding additional XPNET nodes and spreading out the configuration of processes and stations. If not, instead of error 30's, the XPNET node could start to experience PFS issues (error 31 Unable to obtain file-system buffer space). In addition to increasing the values 16383, a new EMS event (4058) has been added that will be generated as part of the XPNET statistics to display the data returned from MESSAGESYSTEMINFO which will externalize the current numbers in use in that XPNET node. 21-12-14;12:53:40.646 \PROD.$P1AN ACI.XPNET.4100 4058 CONTROLMESSAGESYSTEM STATS: INPUT MAX 16383 CURR 101; OUTPUT MAX 16383 CURR 104 Implementation: Install the new BASE file on the XPNET subvol and rebuild the NETWORK using the NETB file. Install the new NETTPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None. SCR #3844 05/10/22 jb and mmd NETTPLS - N41EMS.EMS02PS NETTPLO - N41EMS.EMS02PO TCPTPLS - U10TCPL.TCP04PS TCPTPLO - U10TCPL.TCP04PO Reference Internal Symptom: XPNET should not indicate HPE available features. Problem: Log message indicates versions of CLIM needed. Change: Changed log message to inform the user to check with HPE, and added them to the external TCPIP programs as well. Implementation: Install the new NETTPLS file and the new TCPTPLS/O files and re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None Code Review: CR-XPNET-158 SCR #3845 05/19/22 jb PATH - rel2^ver1^path08^051922 Reference H24-418370 Symptom: 4.1 version of PATH causes same condition as seen for 3833 Station goes ABNORMAL. Problem: The new 4.1 CTS structures were not updated in PATH Change: Updated PATH to use the new structures. Implementation: Put the new file in the XPNET subvol and restart The PATH executalbes from pathway. Dependencies: No dependencies. Code Review: CR-XPNET-160 SCR #3867 10/29/2022 mmn XPNET 3.1 BASE - REL3^VER1^BASE^REL46^20221029 - REL3^VER1^ONCF^SYS22^20221029 - REL3^VER1^NSTP09^20221029 - REL3^VER1^LCNS04^20221029 - REL3^VER1^EXEC22^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N31GLBL.GLBL20 NETDDLS - N31GLBL.GDDL07DS NETDC - N31GLBL.GDDL07DC NETDTAL - N31GLBL.GDDL07DT NETDFUP - N31GLBL.GDDL07DZ NETTPLS - N31EMS.EMS13PS NETTPLO - N31EMS.EMS13PO NETETCL - N31EMS.EMS12EA NETEC - N31EMS.EMS12EC NETEDDL - N31EMS.EMS12ES NETETAL - N31EMS.EMS12ET NETECOB - N31EMS.EMS12EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 3.2 BASE - REL3^VER2^BASE^REL19^20221029 - REL3^VER2^ONCF^SYS06^20221029 - REL3^VER2^NSTP04^20221029 - REL3^VER2^LCNS01^20221029 - REL3^VER2^EXEC06^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N32GLBL.GLBL09 NETDDLS - N32GLBL.GDDL06DS NETDC - N32GLBL.GDDL06DC NETDTAL - N32GLBL.GDDL06DT NETDFUP - N32GLBL.GDDL06DZ NETTPLS - N32EMS.EMS01PS NETTPLO - N32EMS.EMS01PO NETETCL - N32EMS.EMS01EA NETEC - N32EMS.EMS01EC NETEDDL - N32EMS.EMS01ES NETETAL - N32EMS.EMS01ET NETECOB - N32EMS.EMS01EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 3.3 BASE - REL3^VER3^BASE^REL24^20221029 - REL3^VER3^ONCF^SYS08^20221029 - REL3^VER3^NSTP04^20221029 - REL3^VER3^LCNS01^20221029 - REL3^VER3^EXEC09^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N33GLBL.GLBL09 NETDDLS - N33GLBL.GDDL03DS NETDC - N33GLBL.GDDL03DC NETDTAL - N33GLBL.GDDL03DT NETDFUP - N33GLBL.GDDL03DZ NETTPLS - N33EMS.EMS02PS NETTPLO - N33EMS.EMS02PO NETETCL - N33EMS.EMS02EA NETEC - N33EMS.EMS02EC NETEDDL - N33EMS.EMS02ES NETETAL - N33EMS.EMS02ET NETECOB - N33EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 3.4 BASE - REL3^VER4^BASE^REL23^20221029 - REL3^VER4^ONCF^SYS04^20221029 - REL3^VER4^NSTP04^20221029 - REL3^VER4^LCNS01^20221029 - REL3^VER4^EXEC06^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N34GLBL.GLBL05 NETDDLS - N34GLBL.GDDL02DS NETDC - N34GLBL.GDDL02DC NETDTAL - N34GLBL.GDDL02DT NETDFUP - N34GLBL.GDDL02DZ NETTPLS - N34EMS.EMS02PS NETTPLO - N34EMS.EMS02PO NETETCL - N34EMS.EMS02EA NETEC - N34EMS.EMS02EC NETEDDL - N34EMS.EMS02ES NETETAL - N34EMS.EMS02ET NETECOB - N34EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 SVNCPI - REL3^VER4^NCP08^20221029 - REL3^VER4^RN06^20221029 - REL3^VER4^REL12^20221029 XPNET 4.0 BASE - REL4^VER0^BASE^REL18^20221029 - REL4^VER0^ONCF^SYS04^20221029 - REL4^VER0^NSTP03^20221029 - REL4^VER0^LCNS02^20221029 - REL4^VER0^EXEC06^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N40GLBL.GLBL02 NETDDLS - N40GLBL.GDDL01DS NETDC - N40GLBL.GDDL01DC NETDTAL - N40GLBL.GDDL01DT NETDFUP - N40GLBL.GDDL01DZ NETTPLS - N40EMS.EMS02PS NETTPLO - N40EMS.EMS02PO NETETCL - N40EMS.EMS02EA NETEC - N40EMS.EMS02EC NETEDDL - N40EMS.EMS02ES NETETAL - N40EMS.EMS02ET NETECOB - N40EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 XPNET 4.1 BASE - REL4^VER1^BASE^REL09^20221029 - REL4^VER1^ONCF^SYS02^20221029 - REL4^VER1^NSTP02^20221029 - REL4^VER1^LCNS01^20221029 - REL4^VER1^EXEC03^20221029 - T0000D45_29OCT22_LCNS10_LLIB07 GLOBAL - N41GLBL.GLBL02 NETDDLS - N41GLBL.GDDL01DS NETDC - N41GLBL.GDDL01DC NETDTAL - N41GLBL.GDDL01DT NETDFUP - N41GLBL.GDDL01DZ NETTPLS - N41EMS.EMS03PS NETTPLO - N41EMS.EMS03PO NETETCL - N41EMS.EMS02EA NETEC - N41EMS.EMS02EC NETEDDL - N41EMS.EMS02ES NETETAL - N41EMS.EMS02ET NETECOB - N41EMS.EMS02EX LIVERIFY - T0000J06_29OCT22_LCNS10_LVFY07 - T0000D45_29OCT22_LCNS10_LLIB07 Reference: Internal Symptom: N/A Problem: Inconsistent license enforcement across XPNET releases. Change: Added logic to releases 3.1 thru 4.1 to standardize license enforcement. The following enforcement is now standard across releases 3.1 thru 4.1 of XPNET: 1. License expiration warnings will be issued starting 30 days prior to expiration, increasing in frequency as the expiration date nears and is passed. 2. If the license is less than 180 days past expiration XPNET will not cease execution and will be able to be restarted. 3. When the license is 180 days past expiration, XPNET will cease execution and will not be able to be restarted. To distinguish licenses issued before this SCR and those that were issued after, we have incremented a license header informational field (modification number) from 5 to 6. All new shipments of XPNET that include this SCR will be accompanied with a format 6 license with an expiration date that matches the expiration date of your XPNET contract. It is expected that customers will make use of the format 6 license with the version of XPNET containing this SCR. In addition to the standardized enforcement, the following scenarios are accommodated in the new versions of release 3.1 thru 4.1 of XPNET: 1. Use of a version 5 license: a. If the license is not expired, standardized enforcement will be followed. b. If the license contains an expiration date is farther in the future than the end of your XPNET contract, the 180-day temporary allowance will be started. At the end of 180 days, XPNET will cease execution and will not be able to be restarted. c. If the license is expired, the 180-day temporary allowance will be started. At the end of 180 days, XPNET will cease execution and will not be able to be restarted. 2. Use of a version 6 license: a. If the license is not expired, standardized enforcement will be followed. b. If the license is expired, XPNET will continue to start and execute until it reaches 180 days past expiration, at which time XPNET will cease execution and will not be able to be restarted. Customer will be warned via event 6492 every 3 hours which will indicate the number of days remaining before a new license file needs to be installed. 22-11-08;12:57:38.491 \PROD.$P1AN ACI.XPNET.4100 6492 Old format XPNET LICENSE file \PROD.$SYS.XPNET.LI170831 is in use. XPNET Node will stop in 160 days. Contact your ACI customer manager to order a new license. If a new format license file is expired more than 180 days the XPNET node will stop and not restart. This was done to be consistent with all the other licensed ACI products Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Install the new NETTPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Validate the new license file is installed using the LIVERIFY macro. If the most recent license file installed is still the old format the following will be shown: This license expires on (yyyy-mm-dd): 2050-12-30 ******************************************* >>> This is an OLD format License <<< >>> XPNET node will STOP after 180 days <<< ******************************************* Contact your ACI customer manager to order a new license Dependencies: No dependencies. Code Review: CR-XPNET-181 SCR #3868 11/14/2022 des BASE - REL3^VER3^BASE^REL25^20221114 REL3^VER3^DCOM07^20221114 BASE - REL3^VER4^BASE^REL24^20221114 REL3^VER4^DCOM07^20221114 BASE - REL4^VER0^BASE^REL19^20221114 REL4^VER0^DCOM06^20221114 BASE - REL4^VER1^BASE^REL10^20221114 REL4^VER1^DCOM03^20221114 SSLLIBI - T0000H06_03_STGSSLNLIB_18NOV2022_6_0_3_0 STGKM - T0000H06_03_STGKM_30MAR2022_6_0_2_3 T0000H06_03_STGSSLLIB_12OCT2022_6_0_2_17_SPCL Reference Internal Symptom: There are two problems this SCR fixes: - A CERTSREFRESH command is issued and the following log message is seen: ACI_SSL_CERTIFICATE_REFRESH Error 5 for the current Certificate Refresh command. Error 5 is an invalid password. - After a successful CERTSREFRESH command was executed, the customer executed another CERTSREFRESH to go back to the previous certificate. The command seems to work, but it fails to switch back to the previous certificate. Problem: Two things can cause the first problem: - The password being passed to the SSLLIBI routine ACI_SSLCERTIFICATE_REFRESH isn't null terminated, and this routine expects it to be. - In 4.1 only, the code looks at every device in the configuration. We use the last device's definition for the password being passed to the routine. This may not always be valid. The cause for the second problem: - A problem in the SSLLIBI routine ACI_SSLCERTIFICATE_REFRESH. Change: For problem one: - The code makes sure the password is null terminated. - While looping through the devices, when a valid device is found it's information is saved off. We then use that saved information in the call to ACI_SSLCERTIFICATE_REFRESH. For problem two: - A change was made in the SSLLIBI routine Implementation: Install the new BASE, SSLLIBI and STGKM files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-182 SCR #3869 11/30/2022 gjd XPNET 4.1 BASE - REL4^VER1^BASE^REL10^20221114 - REL4^VER1^ONCF^STA04^20221130 SVNCPI - rel4^ver1^rel03^20221130 - rel4^ver1^ncp02^20221130 XPNET 4.0 BASE - REL4^VER0^BASE^REL19^20221114 - REL4^VER0^ONCF^STA06^20221130 SVNCPI - rel4^ver0^rel07^20221130 - rel4^ver0^ncp04^20221130 XPNET 3.4 BASE - REL3^VER4^BASE^REL24^20221114 - REL3^VER4^ONCF^STA07^20221130 SVNCPI - rel3^ver4^rel13^20221130 - rel3^ver4^ncp09^20221130 XPNET 3.3 BASE - REL3^VER3^BASE^REL25^20221114 - REL3^VER3^ONCF^STA06^20221130; SVNCPI - rel3^ver3^rel15^20221130 - rel3^ver3^ncp11^20221130 Reference Case H24-467724 (3486896 ) Symptom: HINFO Station command causes XPNET to Dump. Problem: HINFO command is done on a IPSC station that has a TCPLISTENLINE configred pointing to an existing IPSL Line that does not have a corresponding IPSL Station configured. Code is not checking to ensure that the corresponding station exists and tries to access the station pointer that is set to zero causing the dump. Change: Added code to validate the IPSL station pointer. Code will fail the command and return "no stations configured" to NCPCOM. Implementation: Install the new SVNCPI file on XPNET subvol. STOP and restart the SVNCPI process. Dependencies: No dependencies. Code Review: CR-XPNET-xxx SCR #3871 12/14/2022 mmn BASE - REL4^VER1^BASE^REL10^20221114 - REL4^VER1^EXEC04^20221215 BASE - REL4^VER0^BASE^REL19^20221114 REL4^VER0^EXEC07^20221215 BASE - REL3^VER4^BASE^REL24^20221114 REL3^VER4^EXEC07^20221215 BASE - REL3^VER3^BASE^REL25^20221114 REL3^VER3^EXEC10^20221215 BASE - REL3^VER2^BASE^REL20^20221215 REL3^VER2^EXEC07^20221215 BASE - REL3^VER1^BASE^REL47^20221215 REL3^VER1^EXEC23^20221215 Reference: Case H24-471603 Symptom: Following an ADD NODE command event 6405 was generated every two hours. 22-12-10;13:08:48.475 \SYS1.$P1AN ACI.XPNET.4000 6405 XPNET experienced memory corruption error 2. Process will continue. Problem: As part of the license enforcement changes added by SCR 3867 an additional license verification check was added when an ADD NODE command is done. This logic did not properly reset an internal flag causing a sanity check to fail which generates event 6405. Change: Corrected the ADD NODE logic to fix this issue. NOTE: This does not cause any memory corruption to any message data and the NODE will continue to process transactions, restart and function correctly even though this event is being generated. A work around is to STOP/START the NODE after the ADD NODE command and this event will no longer occur. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: No dependencies. Code Review: CR-XPNET-184 s3925    09/16/24    1.0.01    rak RPCGEN - REL1_VER0_RPCG01_20240916 - REL1_VER0_XNCG01_20240916 Reference: Case H24-609288 ( 03655260 ) Symptom: RPCGEN failing compiles with large RPC source files. Problem: Buffer was too small for some files and second read was not processed correctly. Change: Increased FREAD BUFFSIZE to ensure handling of files up to 128K sized and implemented. Also, updated XMPL globals to include all functions to avoid errors/warnings during compilation. Implementation: Install new RPCGEN. Code Review: CR-XPNET-232 Dependencies: none